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PURSUANT TO 37 C.F.R. § 1.322 



Attention: Certificate of Corrections Branch 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

Dear Sir: 

This is a request for issuance of the accompanying Certificate of Correction pursuant to 35 
U.S.C. §254 and 37 C.F.R. § 1.322(a). The Assignee of Record, UTStarcom, Incorporated, 
seeks to correct mistakes of clerical, typographical nature and of minor character in the above- 
identified Patent. The corrections are as follows: 

In Claim 1, column 25, line 43, delete "reply". 

In Claim 1, column 25, line 45, delete "network". 

In Claim 4, column 26, line 5, delete "reply" and replace with "response". 

In Claim 4, column 26, line 7, delete "configuration". 

In Claim 5, column 26, line 9, delete "the" and replace with "a". 

In Claim 9, column 26, line 45, insert "third" between "the" and "network". 

In Claim 9, column 26, line 46, delete "Internet Protocol". 

In Claim 9, column 26, line 53, delete "reply" and replace with "response". 

In Claim 9, column 26, line 53, insert "third" between "the" and "network". 

In Claim 9, column 26, line 54, delete "reply" and replace with "response". 

In Claim 10, column 27, line 2, delete "control node" and replace with "second network device". 
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In Claim 12, column 27, line 28, insert "and" at the end of the line. 

In Claim 15, column 27, line 50, delete "form" and replace with "from". 

In Claim 16, column 27, line 58, insert "Function" between "Control" and "node". 

In Claim 17, column 27, line 67, delete "a" and replace with "the". 

In Claim 17, column 28, line 2, delete "device" and replace with "devices". 

In Claim 17, column 28, line 8, insert "and" at the end of the line. 

In Claim 22, column 28, line 58, delete "instruction" and replace with "instructions". 

In Claim 24, column 29, line 9, delete "comprise" and replace with "comprises". 

In Claim 25, column 30, line 4, delete "is" and replace with "if". 

The Assignee respectfully submits that the requested corrections do not constitute new 
matter, nor do they require substantive examination of the file. The Assignee further respectfully 
submits that the above-mentioned error was a mistake of the Patent and Trademark Office and, thus, 
the Assignee believes that no fee is due. The reasons that Assignee believes the above-mentioned 
error to be that of the Patent and Trademark Office are detailed in the following paragraphs. If the 
Examiner believes otherwise, the Assignee authorizes the Commissioner to deduct any fee from the 
Deposit Account No. 13-2490 pursuant to 37 C.F.R. §§ 1.20(a) and 1.323. 

On December 28, 2006, in response to the Notice of Allowance mailed October 3, 2006, 
Applicant submitted, together with the issue fee, an amendment under 37 C.F.R. § 1.312 (attached 
hereto as "Exhibit A") to address formal matters in the allowed claims. This amendment was not 
entered, pursuant to a Response to Rule 312 Communication mailed February 5, 2007 (attached 
hereto as "Exhibit B"). 

Applicant and Supervising Examiner Chin discussed the application by telephone on February 
20, 2007. During this discussion, agreement was reached between Applicant and Examiner Chin 
that certain amendments would be entered prior to issuance. Those amendments, which Examiner 
Chin agreed addressed matters of form and did not require reopening prosecution on the merits, 
were submitted by Applicant that same day as a supplementary amendment under 37 C.F.R. § 1.312 
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(attached hereto as "Exhibit C"). However, the patent (No. 7,193,985 Bl, attached hereto as 
"Exhibit D") issued (on March 20, 2007) without reflecting that supplementary amendment. 

Thus, it is the substance of that February 20, 2007 supplementary amendment that is 
reflected in the enclosed Certificate of Correction. Consideration of this request and issuance of the 
Certificate are respectfully requested. If there are any questions regarding this communication, 
please contact the undersigned at 312-913-3317. 

Respectfully submitted, 

Dated: June 25. 2007 By: /Daniel P. Williams/ 

Daniel P. Williams 
Registration No. 58,704 
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EXHIBIT A 



'I PATENT 
[E UNITED STATES PATENT AND TRADEMARK OFFICE 

(MBHB Docket No. 01-469) 



In the Application of: 

Lewis et al. 

Serial No.: 09/881,649 

Filing Date: June 14,2001 

For: System and Method for Managing 

Foreign Agent Selections in a Mobile 
Internet Protocol Network 

Mail Stop Issue Fee 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

AMENDMENT UNDER 37 C.F.R. § 1.312 

Dear Sir: 

In response to the Notice of Allowance mailed on October 3, 2006 in the above- 
referenced matter, Applicants respectfully submit the following amendments under 37 C.F.R. 
§ 1.312 to address formal matters in the allowed claims. 

AMENDMENTS TO THE CLAIMS begin on page 2, and REMARKS begin on page 
12 of this paper. 



Examiner: AjitPatel 
Group Art Unit: 2616 



McDonnell Boehnen Hulbert & Berghofl" LLP 
300 South Wacker Drive 
Chicago, IL 60606 
Telephone: (312)913-0001 



AMENDMENTS TO THE CLAIMS 

1. (currently amended) A method for providing Internet Protocol communication 
services in a communication network, the method comprising: 

detecting a communication session associated with a client device on a first network 

device; 

sending a first message from the first network device to a second network device, the first 
message comprising a registration request; 

determining on the second network device a network address of a third network device 
for providing communication services for the communication session associated with the client 
device; 

sending a first response message from the second network device to the first network 
device, the first response message comprising a registration reply message including the network 
address of the third network device; and 

establishing a communication session between the client device and the third network 
device specified in the first response reply-message, the third network device arranged to provide 
communication services to the client n e twork device. 

2. (original) The method of claim 1, wherein the client device comprises a mobile 
Internet Protocol client device, the first network device comprises a radio node entity, the second 
network device comprises a control node entity, and the third network device comprises a foreign 
agent. 
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3. (original) The method of claim 1, wherein the Internet Protocol communication 
services comprise mobile Internet Protocol communication services or simple Internet Protocol 
communication services. 

4. (currently amended) The method of claim 1, wherein the step of determining the 
network address of the third network device comprises: 

determining whether the client device is a registered client device; if so, 

retrieving a client device record to determine a network address of a network device 

arranged to provide Internet Protocol communication services to the client device; 

retrieving a first network device configuration record comprising at least one network 

address of at least one network device for providing Internet Protocol communication services to 

client devices; 

determining whether the first network device configuration record comprises the network 
address of the network device specified in the client device record; and if so, 

sending the first reply -response message comprising the network address of the network 
device specified in the client device configuration record. 



5. (currently amended) The method of claim 4, wherein if the client device is not the 
^registered network device: 

retrieving the first network device configuration record comprising the at least one 
network address of the at least one network device for providing Internet Protocol 
communication services to client devices; 

McDonnell Boehnen Hulbert & BerghofT LLP t 
300 South Wacker Drive J 
Chicago, IL 60606 
Telephone: (312)913-0001 




retrieving a status information record for each of the at least one network device arranged 
to provide Internet Protocol communication services to client devices, the status information 
record comprising at least one load factor associated with the network device in the record; and 

determining a network address of a network device for providing Internet Protocol 
communication services to the client device based on the at least one load factor associated with 
the network device and at least one threshold value associated with the at least one load factor. 

6. (original) The method of claim 5, wherein the at least one load factor comprises a 
call load factor, a processing power load factor, or a memory load factor. 

7. (original) The method of claim 1, further comprising: 

receiving on the second network device at least one status information message from at 
least one network device arranged to provide Internet Protocol communication services to client 
devices, the at least one status information message comprising at least one load factor associated 
with a network device sending the at least one status information message; and 

creating at least one status information record upon receiving the at least one status 
information message from the at least one network device. 

8. (original) The method of claim 7, wherein the at least one status information 
message is received periodically from the at least one network device arranged to provide 
Internet Protocol communication services to the client devices. 
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9. 



(currently amended) The method of claim 1 , further comprising: 



receiving a second message from the third network device- 




communication 



th e client d e vic e, the second message comprising a request for 



authentication data of the client device; 

retrieving a client device record on the second network device; 

determining whether the client device record comprises the authentication data of the 
client device; if so, 

sending a second feplv -response message to the third network device, the second &pfy 
response message comprising the authentication data of the client device. 

10. (currently amended) The method of claim 1 , further comprising: 
receiving a first registration update message from the third network device on the second 
network device; 

determining whether the third network device is a network device last serving the client 
device based on a client device record; if not, 

sending a second registration update message from the second network device to the 
network device last serving the client device; and 

terminating a communication link associated with the client device on the network device 
last serving the client device responsive to receiving the second registration update message from 
the control nod e second network device . 
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1 1 . (original) A method for providing Internet Protocol communication services in a 
communication network, the method comprising: 

receiving a registration request message from a radio node on a control node, the 
registration request message comprising a request to register a mobile client detected on the radio 
node with a foreign agent; 

determining whether the mobile client is associated with at least one active 
communication session; if so, 

determining a last serving foreign agent associated with the mobile client; 

determining whether the last serving foreign agent is available and associated with the 
radio node; and, if so, 

sending a registration reply message from the control node to the radio node, the 
registration reply message comprising a network address of the last serving foreign agent. 

12. (currently amended) The method of claim 1 1 , further comprising: 
determining on the control node a new foreign agent for the mobile client if the last 

serving foreign agent is not available or not associated with the radio node; 

sending a registration reply message from the control node to the radio node, the 
registration reply message comprising a network address of the new foreign agent; 

sending a registration update message from the control node to the last serving foreign 
agent; and 
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terminating at least one communication session associated with the mobile client on the 
last serving foreign agent responsive to receiving the registration update message on the last 
serving foreign agent. 

13. (original) The method of claim 12, wherein the step of determining the new 
foreign agent comprises: 

retrieving a radio node record comprising a plurality of foreign agents; 

retrieving a status information record for each of the plurality of foreign agents, the status 
information record comprising at least one load factor associated with the foreign agent in each 
status information record; and 

determining the new foreign agent based on the at least one load factor in each status 
information record for each of the plurality of foreign agents. 

14. (original) The method of claim 13, wherein the at least one load factor comprises 
a call load factor, a processing power load factor, a memory usage factor, or an aggregate call 
throughput factor. 

15. (currently amended) The method of claim 13, further comprising: 

receiving the at least one load factor fefm- from the plurality of foreign agents on the 
control node; and 

creating the status information record for each of the plurality of foreign agents 
responsive to receiving the at least one load factor on the control node. 
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16. (currently amended) The method of claim 11, wherein the mobile client 
comprises a mobile Internet Protocol client, and the radio node comprises a Base Station Control 
node, a Packet Control Function node, or a Radio Network node. 

17. (currently amended) An Internet Protocol working device for providing Internet 
Protocol communication services to mobile client devices, the device comprising: 

a central processing unit; 

a first interface for communicating with at least one radio node, the first interface for 
receiving a registration request message from a radio node upon detecting a communication 
session associated with a mobile client on a-the radio node; 

a second interface for communicating with a plurality of network d e vic e devices 
comprising a plurality of foreign agents, the second interface for receiving load status 
information data and mobile client information data from the plurality of network devices 
comprising the plurality of foreign agents; 

at least one memory unit for storing the mobile client information data and the load status 
information data; and 

a computer readable medium comprising a first set of instructions executed by a computer 
for processing the registration request message from the radio node responsive to receiving the 
registration request message from the radio node and for generating a registration reply message 
comprising a network address of at least one of the plurality of network devices comprising the 
plurality of foreign agents; 
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wherein the network address specified in the registration reply message is determined 
using a second set of instructions for selecting network devices comprising foreign agents upon 
receiving registration request messages from the at least one radio node, the second set of 
instructions arranged to use the client device information data and the load status information 
data stored in the at least one memory unit. 

18. (original) The Internet Protocol working device of claim 17, wherein the Internet 
Protocol communication services comprise mobile Internet Protocol communication services or 
simple Internet Protocol communication services. 

19. (original) The Internet Protocol working device of claim 17, wherein the at least 
one radio node communicating with the Internet Protocol working device via the first interface 
comprises a Base Station Controller node, a Packet Control Function node or a Radio Network 
Node. 

20. (original) The Internet Protocol working device of claim 17, wherein the second 
set of instructions is used to determine the network address in the registration reply message 
based on mobile session information data associated with the client device detected on the radio 
node, the mobile session information data comprising the network address of the network device 
arranged to provide Internet Protocol communication service to the client device. 
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2 1 . (original) The Internet Protocol working device of claim 1 7, wherein the at least 
one memory unit further comprises at least one load threshold level, the second set of 
instructions using the load status information data and the at least one threshold level to 
determine the network address specified in the registration reply message. 

22. (currently amended) The Internet Protocol working device of claim 21, wherein 
the at least one memory unit further comprises at least one configuration record for the at least 
one radio node, the at least one configuration record comprising at least one network address 
associated with at least one network device comprising foreign agents arranged to provide 
Internet Protocol communication services to the at least one radio node in the at least one 
configuration record, and the second set of instruction instructions using a configuration record 
of the radio node associated with the registration request message, the at least one threshold level 
and the load status information data of the at least one network device specified in the 
configuration record of the radio node to determine the network address specified in the 
registration reply message. 

23. (original) The Internet Protocol working device of claim 17, wherein the mobile 
session information data stored in the at least one memory unit comprises authentication data 
associated with client devices. 
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24. (currently amended) The Internet Protocol working device of claim 23, further 
comprising: 

a third set of instructions for processing a registration request message comprising an 
authentication data request for authentication data of the client device from the network device 
determined using the second set of instructions and generating a registration reply message 
comprising authentication data of the client device if the mobile session information data 
compris e comprises the authentication data of the client device. 

25. (currently amended) The Internet Protocol working device of claim 17, wherein 
the second set of instructions is arranged to determine whether the network address specified in 
the registration reply message is associated with a network address of a last serving network 
device associated with the client device, and send a registration update message to the last 
serving network device is-if the network device in the registration reply message is not associated 
with the network address of the last serving network device. 

26. (original) The Internet Protocol working device of claim 25, wherein the 
registration update message comprises a request to terminate at least one communication session 
associated with the client device on the last serving network device. 

27. (original) The Internet Protocol working device of claim 17, wherein the first 
interface and the second interface include a software interface or a hardware interface. 
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REMARKS 

The foregoing amendments merely address matters of form and do not require reopening 
prosecution on the merits. If the Examiner has any questions regarding this communication, 
please contact the undersigned by telephone at 312-913-3317. 



Respectfully Submitted, 

McDonnell Boehnen Hulbert & Berghoff LLP 



Date: December 28. 2006 




Daniel P. Williams 
Reg. No. 58,704 
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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 



1 . M The amendment filed on 03 January 2007 under 37 CFR 1.312 has been considered, and has been: 

a) □ entered. 

b) □ entered as directed to matters of form not affecting the scope of the invention. 

c) □ disapproved because the amendment was filed after the payment of the issue fee. 

Any amendment filed after the date the issue fee is paid must be accompanied by a petition under 37 CFR 1 .313(c)(1 ) 
and the required fee to withdraw the application from issue. 

d) S disapproved. See explanation below. 

e) □ entered in part. See explanation below. 

The addition and/or deletion to the claims changes the scope of the claims which require further search and/or 
consideration. 
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U.S. Patent and Trademark Office 
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Reponse to Rule 312 Communication 



Part of Paper No. 20070201 




UNITED STATES PATENT AND TRADEMARK OFFICE 
(MBHB Docket No. 01-469) 



In the Application of: 

Lewis et al. 

Serial No.: 09/881,649 

Filing Date: June 14, 2001 

For: System and Method for Managing 

Foreign Agent Selections in a Mobile 
Internet Protocol Network 

Mail Stop Issue Fee 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 223 1 3- 1 450 



Examiner: AjitPatel 
Group Art Unit: 2616 



I'1 



AMENDMENT UNDER 37 C.F.R. § 1.312 

Dear Sir: 

In response to the Notice of Allowance mailed on October 3, 2006 in the above- 
referenced matter, Applicants respectfully submit the following amendments under 37 C.F.R. 
§ 1 .3 12 to address formal matters in the allowed claims. 



AMENDMENTS TO THE CLAIMS begin on page 2, and REMARKS begin on page 
12 of this paper. 
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EXHIBIT C 



Primary Examiner: Ajit Patel 
Supervising Examiner: Wellington Chin 

Group Art Unit: 2616 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

(MBHB Docket No. 01-469) 

In the Application of: 

Lewis et al. 

Serial No.: 09/881,649 

Filing Date: June 14, 2001 

For: System and Method for Managing 

Foreign Agent Selections in a Mobile 
Internet Protocol Network 

Mail Stop Issue Fee 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

SUPPLEMENTARY AMENDMENT UNDER 37 C.F.R. § 1.312 

Dear Sir: 

On December 28, 2006, in response to the Notice of Allowance mailed October 3, 2006 
in the above-referenced matter, Applicant submitted, together with the issue fee, an amendment 
under 37 C.F.R. § 1.312 to address formal matters in the allowed claims. This amendment was 
not entered, pursuant to a Response to Rule 312 Communication mailed February 5, 2007. After 
reaching agreement by telephone with Supervising Examiner Chin today, February 20, 2007, 
Applicant submits the following supplementary amendment under 37 C.F.R. § 1.312. 



AMENDMENTS TO THE CLAIMS begin on page 2, and REMARKS begin on page 
12 of this paper. 
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AMENDMENTS TO THE CLAIMS 

1. (currently amended) A method for providing Internet Protocol communication 
services in a communication network, the method comprising: 

detecting a communication session associated with a client device on a first network 

device; 

sending a first message from the first network device to a second network device, the first 
message comprising a registration request; 

determining on the second network device a network address of a third network device 
for providing communication services for the communication session associated with the client 
device; 

sending a first response message from the second network device to the first network 
device, the first response message comprising a registration reply message including the network 
address of the third network device; and 

establishing a communication session between the client device and the third network 
device specified in the first response reply-message, the third network device arranged to provide 
communication services to the client network-device. 

2. (original) The method of claim 1, wherein the client device comprises a mobile 
Internet Protocol client device, the first network device comprises a radio node entity, the second 
network device comprises a control node entity, and the third network device comprises a 
foreign agent. 



McDonnell Boehnen Hulbert & Berghoff LLP 
300 South Wacker Drive 
Chicago, IL 60606 
Telephone: (312)913-0001 



3. (original) The method of claim 1, wherein the Internet Protocol communication 
services comprise mobile Internet Protocol communication services or simple Internet Protocol 
communication services. 

4. (currently amended) The method of claim 1, wherein the step of determining the 
network address of the third network device comprises: 

determining whether the client device is a registered client device; if so, 

retrieving a client device record to determine a network address of a network device 

arranged to provide Internet Protocol communication services to the client device; 

retrieving a first network device configuration record comprising at least one network 

address of at least one network device for providing Internet Protocol communication services to 

client devices; 

determining whether the first network device configuration record comprises the network 
address of the network device specified in the client device record; and if so, 

sending the first reply -response message comprising the network address of the network 
device specified in the client device configuration r ecord. 

5. (currently amended) The method of claim 4, wherein if the client device is not 
the-a_registered network device: 

retrieving the first network device configuration record comprising the at least one 
network address of the at least one network device for providing Internet Protocol 
communication services to client devices; 
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retrieving a status information record for each of the at least one network device arranged 
to provide Internet Protocol communication services to client devices, the status information 
record comprising at least one load factor associated with the network device in the record; and 

determining a network address of a network device for providing Internet Protocol 
communication services to the client device based on the at least one load factor associated with 
the network device and at least one threshold value associated with the at least one load factor. 

6. (original) The method of claim 5, wherein the at least one load factor comprises a 
call load factor, a processing power load factor, or a memory load factor. 

7. (original) The method of claim 1, further comprising: 

receiving on the second network device at least one status information message from at 
least one network device arranged to provide Internet Protocol communication services to client 
devices, the at least one status information message comprising at least one load factor 
associated with a network device sending the at least one status information message; and 

creating at least one status information record upon receiving the at least one status 
information message from the at least one network device. 

8. (original) The method of claim 7, wherein the at least one status information 
message is received periodically from the at least one network device arranged to provide 
Internet Protocol communication services to the client devices. 
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9. (currently amended) The method of claim 1, further comprising: 

receiving a second message from the third n etwork device for providing Internet Protocol 
communication services to the client device, the second message comprising a request for 
authentication data of the client device; 

retrieving a client device record on the second network device; 

determining whether the client device record comprises the authentication data of the 
client device; if so, 

sending a second reply -response message to the third network device, the second reply 
response message comprising the authentication data of the client device. 

10. (currently amended) The method of claim 1, further comprising: 

receiving a first registration update message from the third network device on the second 
network device; 

determining whether the third network device is a network device last serving the client 
device based on a client device record; if not, 

sending a second registration update message from the second network device to the 
network device last serving the client device; and 

terminating a communication link associated with the client device on the network device 
last serving the client device responsive to receiving the second registration update message 
from the eeatre - l-f t ed esecond network device . 
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1 1 . (original) A method for providing Internet Protocol communication services in a 
communication network, the method comprising: 

receiving a registration request message from a radio node on a control node, the 
registration request message comprising a request to register a mobile client detected on the 
radio node with a foreign agent; 

determining whether the mobile client is associated with at least one active 
communication session; if so, 

determining a last serving foreign agent associated with the mobile client; 

determining whether the last serving foreign agent is available and associated with the 
radio node; and, if so, 

sending a registration reply message from the control node to the radio node, the 
registration reply message comprising a network address of the last serving foreign agent. 

12. (currently amended) The method of claim 11, further comprising: 
determining on the control node a new foreign agent for the mobile client if the last 

serving foreign agent is not available or not associated with the radio node; 

sending a registration reply message from the control node to the radio node, the 
registration reply message comprising a network address of the new foreign agent; 

sending a registration update message from the control node to the last serving foreign 
| agent; and 

terminating at least one communication session associated with the mobile client on the 
last serving foreign agent responsive to receiving the registration update message on the last 
serving foreign agent. 
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13. (original) The method of claim 12, wherein the step of determining the new 
foreign agent comprises: 

retrieving a radio node record comprising a plurality of foreign agents; 

retrieving a status information record for each of the plurality of foreign agents, the status 
information record comprising at least one load factor associated with the foreign agent in each 
status information record; and 

determining the new foreign agent based on the at least one load factor in each status 
information record for each of the plurality of foreign agents. 

14. (original) The method of claim 13, wherein the at least one load factor comprises 
a call load factor, a processing power load factor, a memory usage factor, or an aggregate call 
throughput factor. 

15. (currently amended) The method of claim 13, further comprising: 

receiving the at least one load factor form from t he plurality of foreign agents on the 
control node; and 

creating the status information record for each of the plurality of foreign agents 
responsive to receiving the at least one load factor on the control node. 

16. (currently amended) The method of claim 11, wherein the mobile client 
comprises a mobile Internet Protocol client, and the radio node comprises a Base Station Control 
node, a Packet Control Function node, or a Radio Network node. 
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17. (currently amended) An Internet Protocol working device for providing Internet 
Protocol communication services to mobile client devices, the device comprising: 
a central processing unit; 

a first interface for communicating with at least one radio node, the first interface for 
receiving a registration request message from a radio node upon detecting a communication 
session associated with a mobile client on a -the r adio node; 

a second interface for communicating with a plurality of network dev+ee-devices 
comprising a plurality of foreign agents, the second interface for receiving load status 
information data and mobile client information data from the plurality of network devices 
comprising the plurality of foreign agents; 

at least one memory unit for storing the mobile client information data and the load status 
information data; and 

a computer readable medium comprising a first set of instructions executed by a 
computer for processing the registration request message from the radio node responsive to 
receiving the registration request message from the radio node and for generating a registration 
reply message comprising a network address of at least one of the plurality of network devices 
comprising the plurality of foreign agents; 

wherein the network address specified in the registration reply message is determined 
using a second set of instructions for selecting network devices comprising foreign agents upon 
receiving registration request messages from the at least one radio node, the second set of 
instructions arranged to use the client device information data and the load status information 
data stored in the at least one memory unit. 
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18. (original) The Internet Protocol working device of claim 17, wherein the Internet 
Protocol communication services comprise mobile Internet Protocol communication services or 
simple Internet Protocol communication services. 

19. (original) The Internet Protocol working device of claim 17, wherein the at least 
one radio node communicating with the Internet Protocol working device via the first interface 
comprises a Base Station Controller node, a Packet Control Function node or a Radio Network 
Node. 

20. (original) The Internet Protocol working device of claim 17, wherein the second 
set of instructions is used to determine the network address in the registration reply message 
based on mobile session information data associated with the client device detected on the radio 
node, the mobile session information data comprising the network address of the network device 
arranged to provide Internet Protocol communication service to the client device. 

21. (original) The Internet Protocol working device of claim 17, wherein the at least 
one memory unit further comprises at least one load threshold level, the second set of 
instructions using the load status information data and the at least one threshold level to 
determine the network address specified in the registration reply message. 
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22. (currently amended) The Internet Protocol working device of claim 21, wherein 
the at least one memory unit further comprises at least one configuration record for the at least 
one radio node, the at least one configuration record comprising at least one network address 
associated with at least one network device comprising foreign agents arranged to provide 
Internet Protocol communication services to the at least one radio node in the at least one 
configuration record, and the second set of ia - s-ta t et j -en - instructions using a configuration record 
of the radio node associated with the registration request message, the at least one threshold level 
and the load status information data of the at least one network device specified in the 
configuration record of the radio node to determine the network address specified in the 
registration reply message. 

23. (original) The Internet Protocol working device of claim 17, wherein the mobile 
session information data stored in the at least one memory unit comprises authentication data 
associated with client devices. 

24. (currently amended) The Internet Protocol working device of claim 23, further 
comprising: 

a third set of instructions for processing a registration request message comprising an 
authentication data request for authentication data of the client device from the network device 
determined using the second set of instructions and generating a registration reply message 
comprising authentication data of the client device if the mobile session information data 
eempr - is e - comprises the authentication data of the client device. 
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25. (currently amended) The Internet Protocol working device of claim 17, wherein 
the second set of instructions is arranged to determine whether the network address specified in 
the registration reply message is associated with a network address of a last serving network 
device associated with the client device, and send a registration update message to the last 
serving network device is— if the network device in the registration reply message is not 
associated with the network address of the last serving network device. 

26. (original) The Internet Protocol working device of claim 25, wherein the 
registration update message comprises a request to terminate at least one communication session 
associated with the client device on the last serving network device. 

27. (original) The Internet Protocol working device of claim 17, wherein the first 
interface and the second interface include a software interface or a hardware interface. 
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REMARKS 

Applicant thanks Supervising Examiner Chin for his review of the prosecution file, and 
for the courtesy of discussing the application by telephone today, February 20, 2007. During this 
discussion, agreement was reached between Applicant and Examiner Chin that the foregoing 
amendments would be entered prior to issuance. Furthermore, Applicant points out that no 
exhibits, prior art, or patentability arguments were discussed. 

Applicant restates - and Examiner Chin agreed - that the foregoing amendments address 
matters of form and do not require reopening prosecution on the merits. If the Examiner has any 
questions regarding this communication, please contact the undersigned at 312-913-3317. 

Respectfully Submitted, 

McDonnell Boehnen Hulbert & Berghoff LLP 

Date: February 20, 2007 By: /Daniel P. Williams/ 

Daniel P. Williams 
Reg. No. 58,704 
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A system and methods are shown for providing Internet 
Protocol communication services to a mobile client. One 
method includes sending a registration request from a radio 
node to a control node responsive to detecting a mobile 
client in a service area of the radio node. When the control 
node receives the request from the radio node, the control 
node determines a foreign agent to provide communication 
services to the mobile client. In one embodiment, the control 
node determines the foreign agent based on a mobile client 
information record, a radio node record, and a plurality of 
foreign agent records associated with the radio node. In one 
embodiment, the control node may select a last serving 
foreign agent associated with the mobile client. Alterna- 
tively, if the control node selects a different foreign agent 
than the last serving foreign agent, the control node sends a 
registration update message to the last serving foreign agent 
so that the last serving foreign agent may terminate any 
ions associated with the mobile client. 
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FIGURE 8B 
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FIGURE 10C 
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SYSTEM AND METHOD FOR MANAGING 
FOREIGN AGENT SELECTIONS IN A 
MOBILE INTERNET PROTOCOL NETWORK 

This application contains a computer program listing 5 
appendix on a compact disc, which is fully incorporated by 
reference, in compliance with 37 C.F.R. § 1.52(e). The 
compact disc contains a single file named "Appendix.txt" of 
size 127,621 bytes created on Jun. 14, 2001. 
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COPYRIGHT 

A portion of the disclosure of this patent document 
contains material that is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 15 
tion by anyone of the patent disclosure, as it appears in the 
Patent and Trademark Office patent files or records, but 
otherwise reserves all United States and International rights 
whatsoever. 

FIELD OF THE INVENTION 

The present invention relates to communications in 
mobile Internet Protocol ("IP") networks. More particularly, 
it relates to providing a centralized node for managing 25 
foreign agents in such networks. 

BACKGROUND OF THE INVENTION 

Public packet switched networks can be used to carry 30 
traffic to and from a mobile communications device (a 
mobile node), such as a mobile host, or router that changes 
its point of attachment from one network to another. The 
basic architecture of mobile IP data networking is known in 
the art and described in several publications, including the 35 
Request for Comments ("RFC") document RFC 2002 
(1996) (hereinafter "RFC 2002"), which is currently avail- 
able from the Internet Engineering Task Force ("IETF"). 
Persons skilled in the art of mobile IP data networking are 
familiar with that document and devices used to implement 40 
mobile IP data networking in practice. 

In a mobile IP communication network, a mobile node 
communicates with a target host on an IP network by means 
of two devices, a "foreign agent" and a "home agent". One 
example of a mobile IP network that describes that type of 45 
communication is presented in U.S. patent application Ser. 
No. 09/354,659 entitled "Mobile Internet Protocol (IP) Net- 
working with Home Agent and/or Foreign Agent Functions 
Distributed Among Multiple Devices," the entire content of 
which is incorporated herein by reference. Typically, the 50 
foreign agent functionality is incorporated into a router on a 
mobile node's visited network. The foreign agent provides 
routing services for the mobile node while it is registered 
with the home agent. For example, the foreign agent de- 
tunnels and delivers datagrams that were tunneled by the 55 
mobile node's home agent to the mobile node. 

The home agent is typically incorporated into a router on 
a mobile node's home network. The home agent maintains 
current location information for the mobile node. When one 
or more home agents are handling calls for multiple mobile 60 
nodes simultaneously, the home agents are providing, in 
essence, a service analogous to a virtual private network 
service. Each mobile node is typically associated with a 
separate home network and the routing path from that home 
network, through the home agent, to the foreign agent and 65 
mobile node is like a virtual private network for the mobile 
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Mobile IP requires link layer connectivity between a 
mobile node (a mobile entity) and a foreign agent. However, 
in some systems the link layer from the mobile node may 
terminate at a point distant from the foreign agent. Such 
networks are commonly referred to as third generation 
wireless networks. FIG. 1 is a block diagram illustrating a 
network architecture that is typically employed in the third 
generation wireless networks. Referring to FIG. 1, a mobile 
node 10 communicates with a target host 34 on an IP 
network 30 by means of three devices, a radio network node 
16, a packet data serving node 18, and a home agent node 24. 
The physical layer of the mobile node 10 terminates on the 
radio network node 16, and the foreign agent's functionality 
resides on the packet data serving node 18. Typically, the 
radio network node 16 relays link layer protocol data 
between the mobile node 10 and the packet data serving 
node 18, and the packet data serving node 18 establishes, 
maintains and terminates the link layer to the mobile node 
10. For example, the mobile node 10 may be linked to the 
radio network node 16 via a communication link on a radio 
access network. 

The packet data serving node 18 provides routing services 
for the mobile node 10 while it is registered with the home 
agent 24. The packet data serving node 18 de-tunnels and 
delivers datagrams that were tunneled from the home agent 
node 24 via an IP network 20 to the mobile node 10. The 
communication traffic exchanged between the packet data 
serving node 16 and the home agent 24 includes data traffic 
as well as control traffic. The control traffic includes regis- 
tration request or registration reply messages. The control 
traffic terminates at the home agent 24 and the packet data 
serving node 16, while the data traffic is routed between the 
mobile node 10 to the target host 34. The target host 34 may 
be connected to a home network 26 by any number of 
networks, such as the IP networks 20 and 30, or it may be 
directly located on the home network 26. Alternatively, the 
target host 34 may be connected to the home network by 
other types of packet switched networks. 

The home agent 24 may be implemented on a router on 
the mobile node's home network 26. The home agent 24 
maintains current location information data for the mobile 
node 10 such as foreign agent address, mobile home address 
and a secret key shared between the home agent and the 
mobile node. The home agent tunnels data from the target 
host 34 to the packet data serving node 18, and similarly 
provides tunneling services in the reverse direction. More 
information on point-to-point tunnels, such as a Layer 2 
Tunneling Protocol ("L2TP") tunnel may be found in the 
RFC 2661, which is available from IETF. The home agent 
24, therefore, typically implements at least two distinct tasks 
for the mobile node 10. First, the home agent 24 performs a 
registration and authentication process to determine whether 
the mobile node 10 is authorized to access the home network 
26. This may involve, for example, checking the identifica- 
tion of the mobile entity, such as through the use of the 
mobile entity's unique serial number or manufacturing num- 
ber, password authentication, and possibly checking whether 
the mobile entity's account is current and paid. The home 
agent's registration and authentication function may be 
performed in conjunction with, or with the assistance of, a 
second device, such as an authentication, authorization and 
accounting server such as a Remote Authentication Dial-In 
User Service ("RADIUS") server. More information on a 
RADIUS server may be found on in the RFC-2138, which 
is available from IETF. As is known to those skilled in the 
art, the registration process includes receiving and process- 
ing registration request messages from the packet data 
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serving node 18 and sending registration reply messages to 
the packet data serving node 18. 

Similarly to the home agent 24, the packet data serving 
node 18 also performs two distinct tasks for the mobile node 
10. The packet data serving node 18 handles registration and 
session control for the mobile node 10, including sending 
registration request messages to the home agent 24 and 
processing registration reply messages received from the 
home agent 24. Additionally, the packet data serving node 
18 has tunneling responsibilities for forwarding data packets 
to the home agent 24 for ultimate transmission to the target 
host 34, as well as de-tunneling data from the home agent 24 
for ultimate delivery to the mobile node 10. Further, the 
packet data serving node 18 provides authentication, autho- 
rization and accounting services for the mobile node 10. 
Similarly to the home agent node 24, the packet data serving 
node may perform the authentication, authorization and 
accounting functions in conjunction with, or with the assis- 
tance of, an authentication, authorization and accounting 
server, such as a RADIUS server. 

When the mobile node 10 initiates a communication 
session with the radio network node 16 by sending a call 
setup indication to the radio network node 16 across a radio 
communication link, the radio network node 16 initiates a 
registration process with the packet data serving node 18. 
Typically, the radio network node 16 is configured with a 
number of packet data serving nodes that may provide 
services to the mobile node 10. In the known prior art, the 
radio network node 16 has no status information for any of 
the packet data serving nodes that are configured to operates 
with the radio network node 16. Thus, when the radio 
network node 16 initiates the registration process for the 
mobile node 10, the radio network node 16 randomly selects 
a packet data serving node for the mobile node 10. In such 
a system, some of the packet data serving nodes available to 
the radio network node may be quickly overloaded while the 
other ones are rarely used. Further, if a number of consecu- 
tive packet data serving nodes to which the radio network 
node 16 sends registration requests are overloaded, such 
packet data serving nodes most likely reject registration 
requests from the radio network node 16, thus, resulting in 
service delays for the mobile node 10. 

Therefore, some of the problems associated with the 
existing prior art mobile IP networks concern inefficient 
selection of packet data serving nodes by radio network 
nodes. For example, as mentioned in the proceeding para- 
graphs, when the radio network node 16 initiates a registra- 
tion process for the mobile node 10, the radio network node 
16 randomly selects the packet data serving node 18 to 
provide services to the mobile node 10. 

Thus, there is a need for a system and method for an 
intelligent selection of packet data serving nodes in a mobile 
IP network. 

SUMMARY OF THE INVENTION 

The system and method for a packet data serving node 
selection in an IP network are developed. 

An embodiment of a method for providing Internet Pro- 
tocol communication services involves detecting a commu- 
nication session associated with a client device, such as a 
mobile node, on a first network device, such as a radio node, 
and responsive to detecting the communication session, 
sending a first message including a registration request from 
the first network device to a second network device, such as 
a control network entity. When the second network device 
receives the registration request, the second network device 



determines a network address of a third network device 
arranged to provide network services to the client device. 
Responsive to determining the network address of the third 
network device, the second network device sends to the first 

5 network device a first response message including the net- 
work address of the third network device. When the third 
network device receives the first response message a com- 
munication session is established between the client network 
device and the third network device. 

10 In one embodiment, when the second network device 
receives the registration request message, the second net- 
work device determines whether the client device is asso- 
ciated with at least one active communication session. If so, 
the second network device determines the last network 

15 device providing communication services to the client 
device. Responsive to determining the last network device, 
the second network device determines whether the last 
serving node is available to service the client device and 
whether it is associated with the first network device. If so, 

20 the second network device sends a network address of the 
last serving device to the first network device, and the last 
serving device continues providing communication services 
to the client device. If the last serving network device is not 
available to serve the client device, the second network 

25 device determines a new network device to provide com- 
munication services to the client device and sends a network 
address of the new network device to the first network 
device in a registration reply message. Further, the second 
network device sends an update message to the last serving 

30 network device to notify the last serving network device 
regarding the handoff of the client device to the new network 
device. Responsive to receiving the update message, the last 
serving node terminates any communication sessions asso- 
ciated with the client network device. 

35 These as well as other aspects and advantages of the 
present invention will become more apparent to those of 
ordinary skill in the art by reading the following detailed 
description, with reference to the accompanying drawings. 

K BRIEF DESCRIPTION OF THE DRAWINGS 



Exemplary embodiments of the present i 
described with reference to the following drawings, in 

45 FIG. 1 is a block diagram illustrating an example of a 

prior art mobile IP network architecture; 

FIG. 2 is a block diagram illustrating an example of a 

mobile IP network architecture according to an embodiment 

of the present invention; 
50 FIG. 3 is a flow chart illustrating an exemplary method for 

foreign agent discovery process on a foreign agent control 

node according to one embodiment of the present invention; 
FIG. 4 is a message sequence scenario, according to one 

embodiment of the present invention, illustrating an exem- 
55 plary message flow for discovering foreign agents on a 

foreign agent control node using heartbeat message; 

FIG. 5 is a block diagram illustrating an example of a 

heartbeat message format for messages sent from foreign 

agents to a foreign agent control node, according to one 
60 embodiment of the present invention; 

FIG. 6 is a block diagram illustrating an example of a 

heartbeat message format for messages sent from a foreign 

agent control node to foreign agents, according to one 

embodiment of the present invention; 
65 FIG. 7 is a flow chart illustrating a configuration of a radio 

network node according to one embodiment of the present 
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FIGS. 8 A and 8B are a flow chart illustrating a method for 
selecting a foreign agent on a foreign agent control node 
according to one embodiment of the present invention; 

FIG. 9 is a message sequence scenario illustrating an 
example of a message flow for selecting a foreign agent on 
a foreign agent control node according to one embodiment 
of the present invention; 

FIGS. 10A, 10B and IOC are a flow chart illustrating an 
example of a method for authenticating a mobile node 
associated with a foreign agent according to one embodi- 
ment of the present invention; 

FIG. 11 is a message sequence scenario illustrating an 
example of a message flow for a first time mobile Internet 
Protocol registration of a mobile node with a foreign agent 
selected on a control node; 

FIG. 12 is a message sequence scenario illustrating an 
example of a message flow for a first time simple Internet 
Protocol registration of a mobile node with a foreign agent 
selected on a control node; and 

FIG. 13 is a message sequence scenario illustrating a 
mobile node handoff between foreign agents. 

THE DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT(S) 

FIG. 2 is a functional block diagram illustrating an 
embodiment of a preferred network architecture suitable for 
application in the present invention for selecting foreign 
agents for mobile nodes in a mobile IP network. FIG. 2 
describes network entities typically employed in third gen- 
eration mobile IP networks; however, it should be under- 
stood that the present invention is not limited to the network 
architecture described hereinafter, and the methods and 
apparatus described herein may be applied for managing the 
selection of foreign agents in any existing or later developed 
mobile IP systems. Referring to FIG. 2, a client device, such 
as a mobile node 210, communicates with a remote client 
device, such as the target host 34, on the IP network 30. The 
mobile node 210 is connected to a first network device, such 
as a radio node 216, via a radio connection 238 on a radio 
access network. In one embodiment, the radio node may 
include a radio network node ("RNN"), a base station 
control ("BSC") node or a Packet Control Node ("PCN"), 
for example. As illustrated in FIG. 1, the radio node is 
referred hereinafter as a radio network node. According to 
one embodiment of the present invention, the radio network 
node 216 communicates with a second network device, a 
foreign agent control node ("FACN") 220 and a plurality of 
packet data serving nodes ("PDSNs"). The FACN 220 
manages foreign agents selection, such as a packet data 
serving node selection for mobile IP registration purposes. 
The FACN 220 may be referred to herein as a "control 
node", a "foreign agent control node", and the PDSNs may 
be referred herein as "foreign agents". 

The FACN 220 includes a radio node mobile IP interface 
224 for communicating with radio network nodes, such as 
the radio network node 216. When the radio network node 
216 detects a call set up request from the mobile node 210, 
the radio network node 216 requests mobile registration 
service from the FACN 220 over the radio network node 
interface 224. When the FACN 220 receives a registration 
request, the FACN 220 selects a third network device to 
provide network services to the mobile node 210. In one 
embodiment, the FACN 220 selects a PDSN using a set of 
predetermined criteria and sends the selected PDSN network 
address to the radio network node 216. The FACN 220 
further includes a PDSN interface 230 for 



with the pool of PDSNs, such as the PDSNs 232, 234, and 
236. In the embodiment illustrated in FIG. 2, the FACN 220 
communicates via the PDSN interface 230 with FACN- 
managed PDSNs 232, 234, and 236. The PDSNs 232, 234, 

5 and 236 provide their capacity information capabilities, such 
as current call load factors, processing unit load factors, or 
memory load factors, via the PDSN interface 230. 

In one specific embodiment, the PDSN interface 230 and 
the RNN interface 224 may be implemented in a Total 

10 Control Enterprise Network Hub commercially available 
from 3Com Corporation of Santa Clara, Calif. The Total 
Control product includes multiple network interface cards 
connected by a common bus. See "Modem Input/Output 
Processing Signaling Techniques," U.S. Pat. No. 5,528,595, 

1? granted to Dale M. Walsh et al. for a description of the 
architecture of the Total Control product, which is incorpo- 
rated herein by reference herein. However, the interfaces 
may also be implemented in other devices with other hard- 
ware and software configurations and are not limited to 

" u implementations in a Total Control product or the equiva- 
lent. 

In one embodiment, the FACN 220 uses the capacity 
information of the managed PDSNs to determine the ability 

2 _ of a PDSN to handle a new mobile nodes registration. When 
the radio network node 216 registers the mobile node 210 
with the FACN 220, the FACN 220 may first attempt to 
assign the registering mobile node 210 to the PDSN cur- 
rently providing communication services to the mobile 
node. However, if the FACN has no active history for the 
mobile node 210, or if the PDSN currently serving the 
mobile node 210 is unavailable or invalid for the radio 
network node 216, a new PDSN is selected from a PDSN 
pool associated with the registering radio network node 216. 

35 Referring back to FIG. 2, the FACN 220 further includes 
a memory unit 226. The memory unit 226 includes a volatile 
memory unit 226A and a nonvolatile memory unit 226B. In 
one embodiment, before the FACN 220 initiates processing 
of radio network node registration requests, the FACN 220 

40 is configured with a number of configuration records or 
tables that may be stored in the nonvolatile memory unit 
226B or, alternatively, may be stored to a configuration file 
by a system administrator. In an embodiment where the 
nonvolatile records are stored in the configuration file, any 

45 subsequent FACN startups may restore the configuration 
file. The configuration of the FACN 220 may be done via a 
Command Line Interface ("CLI") or a Simple Network 
Management Protocol ("SNMP") interface 228. The CLI/ 
SNMP interface 228 provides a manner in which to add, 

5n delete and modify configuration entries. Any type of inter- 
face that provides an access for configuration may be used 
as an alternative to the interface 226. In one embodiment, a 
hardware platform for the FACN 220 may include a Sun 
Microsystems Netra hardware platform. However, different 

55 hardware platform 

One of the configuration tables in the nonvolatile memory 
226B may include port numbers for exchanging control data 
between the FACN 220, the PDSNs 232, 234, 236 and the 
radio network node 216. For example, the FACN 220 may 

60 employ User Datagram Protocol ("UDP") ports for exchang- 
ing control data with the PDSNs and the radio network node 
216. The FACN 220 may be configured to use an UDP port 
number 697 for exchanging data with the radio network 
node 216. The FACN 220 may further be configured to use 

65 default UDP ports 15000 and 15001 for communicating 
control data with the PDSNs. However, it should be under- 
stood that the present invention is not limited to using these 
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port numbers, and the FACN 220 may employ different ports 
for communicating control data with the radio network node 
and PDSNs. 

The secure communication between network entities in 
communication systems often requires a receiving network 5 
entity to authenticate a sending entity. One example of 
secure communication between network entities involves 
the use of digital keys that are shared by communicating 
network entities. In such an embodiment, when a sending 
entity transmits a message to a receiving entity, the sending lu 
entity runs the message through a message digest algorithm 
using a secret key shared between the sending entity and the 
receiving entity, and produces a value commonly referred to 
as a message digest. The message digest is sent from the 
sending entity along with the message to the receiving entity 15 
that uses the message digest to verify whether the sending 
entity is a trusted entity. To do that, the receiving entity may 
extract the message digest from the received message and 
run the message through the same message digest algorithm. 
In such an embodiment, if the message digest generated on 
the receiving entity matches the one extracted from the 
received message, then, the user is a trusted entity. The 
process for authenticating entities is further described in the 
RFC-2002. However, the embodiments described herein are 
not limited to using the digital keys, and different or equiva- 
lent authentication methods may alternatively be used. 25 

Referring again to FIG. 2, the nonvolatile memory unit 
226B preferably stores a number of digital secret keys. As 
mentioned in the preceding paragraphs, the PDSNs may 
authenticate the mobile node 210 with the assistance of an 
authentication, authorization and accounting ("AAA") 30 
server 240. Thus, one of the keys may include an AAA- 
PDSN secret key that is used on a PDSN and the AAA 
server, such as, for example, access-request or access-accept 
messages, to authenticate messages that are exchanged 
between the two entities during the authentication process. 35 
The AAA server 240 may be a Steel Belted RADIUS, 
Advanced Wireless Edition ("SBR-AWE") provided by a 
service provider "FUNK", for example. In one embodiment, 
the FACN 220 may store a single AAA-PDSN secret key for 
the use between the AAA server and the PDSNs associated 4Q 
with the FACN 220. However, more than one secret key 
could also be used, so that, for example, predetermined sets 
of PDSNs are associated with different secret keys for 
communicating with one or more AAA servers. For 
example, an AAA-PDSN secret key record may include a 
secret key stored with an IP address of an AAA server 45 
assigned to the key. Table 1 illustrates an exemplary FAAA- 
PDSN secret key record. 

TABLE 1 



AAA IP ADDRESS SECRET KEY 



8 

Similarly, the radio network node 216 and the PDSNs 
may use the same secret key. Table 3 illustrates an exem- 
plary radio network node — PDSN secret key record. 

TABLE 3 



SECURITY PARAMETER INDEX SECRET KEY 



Security Parameter Index Secret key for PDSN/radio network 



Further, according to one embodiment, a system operator 
of the FACN 220 may group a number of PDSN IP addresses 
that the FACN 220 will service and may assign a text 
description to each group so that each PDSN managed on the 
FACN 220 is assigned to at least one group. However, the 
present invention is not limited to grouping PDSNs by 
system operators, and PDSNs may be automatically grouped 
to one or more groups, such as default groups, upon report- 
ing to the FACN 220, as will be described in detail below. 
Table 4 illustrates an example of a record for grouping 
PDSNs, where an IP address of a PDSN specified by the 
system operator is assigned to a predetermined group num- 
ber or a group identifier. 

TABLE 4 



PDSN GROUP PDSN IP 
PDSN GROUP # DESCRIPTION ADDRESS LIST 



Group number/Group ID Group Description PDSN IP ADDRESS 



Further, upon an initial FACN startup, the operator has the 
option of configuring a set of radio network node IP 
addresses that the FACN 220 will service. In one embodi- 
ment, a radio network node record may define a list of PDSN 
groups that may be selected to service radio network node 
requests. For example, if the operator fails to assign at least 
one PDSN group to a radio network node, the radio network 
node may be assigned to a default PDSN group when it 
attempts to register with the FACN 220 for the first time. 
Table 5 illustrates an exemplary radio network node-PDSN 
group assignment record in the nonvolatile memory unit 
226B, where a radio network node IP address is assigned to 
one or more PDSN groups. 

TABLE 5 



RADIO 

NETWORK NODE IP ADDRESS PDSN GROUP LIST 



IP address of an radio network A list of PDSN group numbers/Group 
node Ids for the radio network node 



Similarly, the nonvolatile memory unit 226B may store 55 
FACN-PDSN and radio network node-PDSN secret keys. In 
one embodiment, one global secret key may be defined for 
the use between the FACN 220 and all PDSNs associated 
with the FACN 220. Table 2 illustrates an exemplary FACN- 
PDSN secret key record. 60 

TABLE 2 



SECURITY PARAMETER INDEX SECRET KEY 



Security Parameter Index Secret key for PDSN/FACN 



Further, the FACN 220 may keep a number of volatile 
records that are created during the operational stage of the 
FACN 220. For example, such records may be stored on the 
volatile memory unit 226A. The FACN 220 may maintain 
volatile PDSN profile records and volatile mobile node 
records. The FACN 220 creates PDSN profile records as the 
PDSNs report their presence in the network. The PDSN 
profile records are dynamically changed as PDSNs become 
inactive or as new PDSNs are added to the network. Accord- 
ing to an embodiment of the present invention, PDSNs are 
arranged to provide their load status information via periodic 
messages, hereinafter referred to as heartbeat messages. 
Each PDSN is configured to periodically send, for example, 
its processing load factor, call load factor, and/or memory 
load factor to the FACN 220. For example, the processing 
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load factor of a PDSN may be associated with the processing 
capacity of the PDSN, the call load factor may be associated 
with a number of calls that the PDSN is currently serving, 
and the memory load factor may be associated with memory 
resources, either available or used, on the PDSN. According 5 
to one embodiment of the present invention, the FACN 220 
is configured via the CLI/SNMP interfaces 228 with a 
number of threshold levels defining when a PDSN is no 
longer available for selection. For example, a call balance 
threshold may define a call level below which the PDSN 10 
may be selected to service new calls, independently of any 
call balancing mechanisms. In one embodiment, the FACN 
220 may be automatically configured with a number of 
default threshold levels, such as, for example, 100% pro- 
cessing load, 100% memory load, and 4000 calls load level. 15 
In one embodiment, the FACN 220 may be configured with 
a number of thresholds that vary among the various PDSNs. 

If a PDSN fails to send a heartbeat message for a 
predetermined number of consequtive periods, the FACN 
220 may identify such a PDSN as unavailable. Like the other 20 
threshold, this number is preferably configurable in the 
PDSN entries as a "missed heartbeat count" variable. Fur- 
ther, each PDSN profile record may include a lifetime timer 
defining a time interval within which the FACN 220 should 
expect the consecutive heartbeat message. Table 6 illustrates 25 
an example of a PDSN profile record that may be created on 
the FACN 220 for each PDSN during the operational stage 
of the FACN 220. 

TABLE 6 30 



MISSED 

HEARTBEAT LIFETIME LOAD 
PDSN STATUS COUNT TIMER FACTOR 



PDSN IP Inactive/ Number of Heartbeat Processing/ 

messages Call Loading 



Further, the FACN 220 may maintain mobile user infor- 
mation data in mobile node records that are created on the 40 
FACN 220 upon user registrations with a FACN-managed 
PDSN. Each time a mobile node registers with one of the 
FACN-managed PDSNs, the registering PDSN may send the 
mobile node's data, such as an AAA profile and mobile 
session information, to the FACN 220, so that if no record 45 
currently exists for the mobile node, the FACN 220 may 
create a new mobile user profile record, or if such a record 
already exists, the FACN 220 may update the currently 
existing record associated with the mobile user. Further, if 
such a record already exists, but for a different PDSN than 50 
the one sending the update, then, a "PDSN handoff ' has 
occurred, that is, the mobile node has roamed from one radio 
node to a new radio node that is not associated with the 
original serving PDSN, or that the original PDSN is unavail- 
able for some other reasons, such as, its call load is excessive 55 
or it is no longer sending heartbeat messages, for example. 
According to one embodiment, when the FACN 220 detects 
the handoff, the FACN 220 may send an update message to 
the previous PDSN associated with the AAA profile and 
mobile session information. Upon the receipt of this mes- 60 
sage, the previous PDSN may terminate its communication 
link with the previous radio node associated with the mobile 

A mobile user profile record may include a mobile tele- 
phone number or an International Mobile Subscriber Iden- 65 
tity ("IMSI"), a mobile connection identifier ("MOBILE 
NODE-ID"), one or more sessions indexed by a Network 
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Address Identifier ("NAI"), or a NAI user profile. Table 7 
illustrates an exemplary mobile node profile record that may 
be created on the FACN 220 upon receiving registration 
information from a PDSN as the mobile node registers with 
the PDSN. 

TABLE 7 



MOBILE 

IMSI/MOBILE MOBILE PDSN IP SESSION MOBILE 

NODE-ID SESSION NAI ADDRESS STATUS PROFILE 



Mobile phone Mobile session IP address of Active or AAA pro- 
number and NAI the last PDSN idle file of the 



It should be understood that the present invention is not 
limited to the use within the system illustrated in FIG. 2. 
More, fewer or different components, connections, inter- 
faces could also be used. For example, the volatile and 
nonvolatile records described in the preceding paragraphs 
may be stored in one or more databases located on the FACN 
220 or may be stored on a volatile or nonvolatile media in 
a network server in communication with the FACN 220. 
Additionally, the radio node is not limited to the radio 
network node, and different types of radio nodes could also 
be used, such as a Base Station Controller ("BSC") node or 
a Packet Control Function ("PCF") node, for example. 
Further, the arrangements described herein are shown for 
purposes of illustration only, and those skilled in the art will 
appreciate that other arrangements and other elements, such 
as interfaces or functions, whether or not known in the art, 
can be used instead, and some elements may be omitted 
altogether. Additionally, as in most communications appli- 
cations, those skilled in the art will appreciate that many of 
the elements described herein are functional entities that 
may be implemented as discrete components or in conjunc- 
tion with other components, or as firmware or software, in 
any suitable combination and location. 

FIG. 3 is a flow chart illustrating a method 300 for a 
foreign agent discovery process, such as a PDSN discovery 
process. According to one embodiment, the foreign agent 
discovery process is implemented using a network protocol 
between the foreign agents and a control node, such as the 
FACN 220. When the foreign agent starts operating, the 
foreign agent sends an initialization control message to the 
control node, thus, conveying its ability to handle mobile 
node registration requests. Referring to FIG. 3, at step 302, 
a control node receives an initialization control message 
from a foreign agent. Responsive to receiving the initializa- 
tion control message, the control node generates an initial- 
ization control reply message including secret key data. For 
example, the secret key data may include a first secret key 
that may be used when the foreign agent communicates with 
a radio network node, and a second secret key is used when 
the foreign agent communicates with a predetermined AAA 
network server. At step 304, the control node sends the 
initialization control reply message to the foreign agent. 
Further, at step 306, the control node dynamically creates a 
foreign agent profile record and marks the foreign agent as 
an inactive foreign agent. In one embodiment, the dynamic 
foreign agent profile entry may be stored in a memory 
configured to store volatile records. However, different 
embodiments are possible as well. For example, the control 
node may be configured to store the volatile records in one 
or more databases. 



US 7,193,985 Bl 



11 

Responsive to receiving the initialization control reply 
message from the control node, the foreign agent may start 
its normal operation of sending periodic control messages to 
the control node. According to an exemplary embodiment, 
the control messages that are periodically sent from the 5 
foreign agent indicate that the foreign agent is active and 
include load data associated with the foreign agent, such a 
call load factor, processing load factor, and/or memory load 
factor associated with the call, processing and memory 
resources that are currently used by the foreign agent. At 10 
step 308, the control node determines whether a second 
control message has been received from the foreign agent. If 
the second message is not received, the method 300 termi- 
nates, and the foreign agent's inactive status in the foreign 
agent profile record is not changed. If the second control 15 
message is received by the control node, at step 310, the 
control node modifies the foreign agent's inactive status in 
the foreign agent's record to an active status. Further, if the 
second control message includes load factors associated 
with the foreign agent, at step 312, the control node stores 20 
the load factors in the foreign agent profile record. Further, 
the control node may send a reply acknowledgement mes- 
sage to the control node, thus, indicating its active state and 
the receipt of the second message. 

In the method 300, the control node may be the FACN 25 
220, described above, and the foreign agent may be the 
PDSN 232. However, it should be understood that the 
method 300 is not limited to the use of any particular 
hardware or software and fewer, more, different or equiva- 
lent network devices may also be used. 30 

According to an exemplary embodiment, the control 
node, FACN 220, and the associated foreign agents, PDSNs, 
may use a heartbeat messaging mechanism to convey the 
foreign agent availability, control node availability and 
foreign agent load factors. FIG. 4 is an example of a message 35 
sequence scenario 400 illustrating a heartbeat-messaging 
scheme that may be used between a foreign agent and a 
control node. A foreign agent, such as the PDSN 232, starts 
communication with a control node, such as the FACN 220, 
via a Heartbeat Initialization ("INIT") message 402. 40 
Responsive to receipt of the Heartbeat INIT message 402, 
the control node generates a Heartbeat INIT Acknowledge 
message 404, including secret keys to be used on the foreign 
agent for communication with the radio network node 216 
and a predetermined AAA server, and transmits the message 45 
404 to the foreign agent. Subsequently, the foreign agent 
sends to the control node periodic Heartbeat messages 406 
including its processing, memory and call load factors, or a 
status override parameter indicating that the foreign agent is 
unavailable. In accordance with a preferred embodiment, the 50 
heartbeat messages are periodic in nature. The control node 
responds to each periodic heartbeat message with a Heart- 
beat Acknowledge message 408. In one embodiment, the 
Heartbeat Acknowledge message 408 may include a unique 
key tag identifier associated with the AAA server and radio 55 
network node keys. The control node may update keys 
available to the foreign agent, and if one or more keys are 
updated, the control node may define a new key tag identifier 
in a Heartbeat Acknowledge message. If the foreign agent 
receives a new key tag identifier, the foreign agent may 60 
request new keys via a Heartbeat INIT message. 

According to one embodiment, the periodic Heartbeat 
messages are indicative of the foreign agent's activity and 
include foreign agent's load factors. As mentioned in refer- 
ence to the preceding paragraphs, the control node may be 65 
configured to remove a foreign agent from a list of active 
foreign agents if a predetermined number of periodic heart- 
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beat messages are missing or if a predetermined number of 
periodic heartbeat messages fails authentication on the con- 
trol node. According to another embodiment, heartbeat 
messages, such as a Heartbeat INIT and periodic Heartbeat 
messages, may include heartbeat intervals so that the control 
node expects to receive the next heartbeat message from the 
foreign agent prior to an end of the heartbeat interval 
specified by the foreign agent in the previous heartbeat 
message. 

FIG. 5 is a block diagram illustrating a preferred format 
500 of heartbeat messages, such as preferred formats of the 
Heartbeat INIT message 402 and the periodic Heartbeat 
messages 406. The message format 500 includes a plurality 
of fields: an IP header 502, an UDP header 504, a message 
type field 506, a reserved field 508, a length field 510, a 
heartbeat interval field 512, a reserved field 514, a PDSN 
address field 516, and a plurality of sub-fields. The EP 
header 502 may have a format of an IP header. In such an 
embodiment, a destination field in the IP header may include 
an IP address of the control node and a source address field 
may include an IP address of a source foreign agent, such as 
the PDSN 232 of FIG. 2. However, the IP header is not 
limited to the IP header, and different IP header formats 
could also be used. Further, in one embodiment, the UDP 
header format 504 may have a format of the UDP header, for 
instance. Alternative formats for the heartbeat messages may 
also be used. For example, the heartbeat messages may 
include more or fewer fields and/or subfields than are shown 
in FIG. 5, or arrangement of the fields and/or subfields may 
be changed. 

The type field 506 defines a type of the Heartbeat mes- 
sage, such as a PDSN INIT Heartbeat or a PDSN periodic 
Heartbeat. Table 8 illustrates an example of message type 
values for the two messages. Other type values may alter- 
natively be used. 

TABLE 8 



TYPE DETAILS 



0x02 PDSN INIT Heartbeat 

0x01 PDSN periodic Heartbeat 



Further, the reserved fields 508 and 514 may be left blank for 
a future use or, alternatively, eliminated. The length field 510 
may define a message length, for example, in octets, and the 
heartbeat interval 512 may define a time interval during 
which time the control node should receive the next heart- 
beat message. The foreign agent address field 516 includes, 
for example, an IP address of the foreign agent sending the 
message. 

The plurality of sub-fields includes load factors of the 
sending foreign agent. In the message format illustrated in 
FIG. 5, there are three subtype load fields: a call load field 
5 18. a processing usage field 524, and a memory usage field 
536. with the respective length fields 520, 526, and 538, and 
value fields 522, 528, and 534 defining the current load 
factors of the variables defined in the fields 518, 524, and 
536. Table 9 illustrates exemplary values that may be used 
for the subtype fields 518, 524, and 536. However, it should 
be understood that different values for the call load, pro- 
cessing usage, and the memory usage fields could also be 
used. Further, fewer, more, different or equivalent foreign 
agent capacity variables could also be used. 



US 7,193,985 Bl 



14 



Foreign Agent Men 



Further, the message format of FIG. 5 includes an authen- 
tication type field 536 with an identifier of an authentication 10 
mode employed on the foreign agent, a length field 538 
including a length of the authentication field 536, a Security 
Parameter Index ("SPI") fields 540, 542 and an Authenti- 
cator field 544. 

FIG. 6 illustrates an example of a message format 600 for 15 
heartbeat messages that may be sent from the control node 
in response to receiving a heartbeat message from a foreign 
agent, such as the FACN Heartbeat INIT ACK message 404 
or the FACN periodic Heartbeat ACK message 408 illus- 
trated in FIG. 4. The message format illustrated in FIG. 6 is 20 
similar to the one shown in FIG. 5, and includes an IP header 
field 602, an UDP header field 604, a message type field 606, 
a reserved field 608, a length field 610, and a PDSN address 
field 612. Like the message format 500 in FIG. 5, the 
message format 600 is merely an example of a preferred 25 
embodiment and alternative formats may be used. For 
example, the heartbeat messages may include more or fewer 
fields and/or subfields that are shown in FIG. 6, or the 
arrangement of fields and/or subfields may be changed. 

In FIG. 6, the IP header field 602 includes a source 30 
address field with an IP address of the FACN 220, and a 
destination address field with an IP address of a destination 
PDSN. Further, the message type field identifies a type of the 
heartbeat message that is generated by the FACN 220. Table 
10 illustrates an example of type values that may be used to 35 
define a heartbeat INIT ACK message and periodic ACK 
message type. 



TABLE 10 



The message format 600 also includes a key tag value 
field 614, a reserved field 616, a subtype PDSN-radio 
network node key field 618, a length field 620 associated 
with the subtype key field, an SPI field 622, and secret fields 
624. The key tag value field 614 includes a sequential key 50 
tag identifier for the AAA and radio network node keys 
stored on the FACN 220. The sequential key tag identifiers 
may be modified on the FACN 220 each time one or both 
keys are changed. If a PDSN receiving a heartbeat ACK 
message from the FACN 220 detects that a key tag identifier 55 
specified in the received message is different from a key tag 
identifier stored locally on the PDSN, the PDSN may send 
a Heartbeat INIT message to cause the FACN 220 to refresh 
its keys. The subtype PDSN-radio network node key field 
618 identifies the type of a secret key in the secret fields 624. 60 
According to the embodiment illustrated in FIG. 6, the 
subtype PDSN-radio network node key field 618 includes an 
identifier associated with the PDSN-radio network node key 
that is included in the secret key fields 624. 

Further, the message includes a subtype PDSN-AAA key 65 
field 626, a length field 628, an AAA IP address field 630, 
secret fields 632, an authentication type field 634, a length 



field 636, an SPI field 638, and an SPI authenticator field 
640. The subtype PDSN-AAA key field 626 identifies that 
the secret fields 632 include an AAA key that may be used 
between the PDSN and an AAA server. In one embodiment, 
a network address, such as an IP address, of the AAA server 
is specified in the AAA IP address field 630. [What is defined 
in the authentication type, SPI and SPI authenticator fields?] 
Table 1 1 illustrates exemplary type values that may be used 
in the subtype fields 618 and 626. However, different values 
could also be used. 

TABLE 11 



FIG. 7 is a flow chart illustrating a method 700, in 
accordance with a preferred embodiment, for a radio net- 
work node operation. At step 702, a radio network node is 
configured with a network address ol a control node as a 
preferred foreign agent network address. In such an embodi- 
ment, when the radio network node detects a mobile node in 
its service area, the radio network node queries the control 
node prior to attempting to register the mobile node with any 
other foreign agent. The radio network node may be con- 
figured with a number of network addresses of foreign 
agents available to serve mobile nodes in the service area of 
the radio network node. At step 704, the radio network node 
determines whether a new mobile node has been detected in 
its service area. If the radio network node detects a new 
mobile node in its service area, then, at step 706, the radio 
network node sends a registration request to the network 
address of the control node. Otherwise, the method returns 
to step 704. 

At step 708, the radio network node receives a registration 
reply message from the control node. According to a pre- 
ferred embodiment, the registration reply message includes 
a network address of a foreign agent selected on the control 
node. Such selection may be based on a number of the 
selection criteria described in reference to FIGS. 8A and 8B. 
Alternatively, the registration reply message may include a 
rejection code if the radio network node fails an authenti- 
cation process on the control node, for instance. In such an 
embodiment, the radio network node may send a registration 
request message to one of the foreign agents with which the 
radio network node is configured. 

At step 710, the radio network node sends a registration 
request message to the foreign agent node specified in the 
registration reply message from the control node. The reg- 
istration request message may include the mobile node's 
data, such as, for example, a mobile identifier or a network 
address of a home agent associated with the mobile node. At 
step 712, the radio network node receives a registration reply 
message from the foreign agent. The registration reply 
message received on the radio network node may include a 
registration confirmation parameter or a registration rejec- 
tion parameter. If the registration reply message includes the 
registration confirmation parameter, the mobile node may 
initiate establishing of a communication link, such as a 
point-to-point communication link, with the foreign agent. If 
the registration reply message includes the registration rejec- 
tion parameter, the radio network node may retry to register 
with the foreign agent control node or, alternatively, may 
register with another foreign agent with which it was con- 
figured. 
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In the method 700 described in reference to FIG. 7, the 
mobile node may include the mobile node 210, the radio 
network node may include the radio network node 216, the 
foreign agent control node may include the FACN 220, and 
the foreign agent may include the PDSN 232, as illustrated 5 
in FIG. 2. However, the exemplary method is not limited to 
these devices, and fewer, more, or different devices may 
alternatively be used so long as such devices are capable of 
performing the steps recited in FIG. 7. 

As mentioned in the preceding paragraphs, one of the 10 
control node's functions is to select a foreign agent to 
service the radio network node's mobile client registration 
requests. When the control node receives a registration 
request message from the radio network node 216, the 
control node does not process the registration request as a 15 
typical foreign agent normally does. Instead, it selects a 
foreign agent, such as one of the PDSNs 232, 234, or 236 
illustrated in FIG. 2 that can service the mobile client 
registration. The control node may use any appropriate 
selection algorithm to determine a foreign agent that is 20 
suitable to service a mobile client registration. 

FIGS. 8 A and 8B are a flow chart illustrating a method 
800 that may be controlled on a control node for selecting a 
foreign agent to service a mobile client's registration 
request. At step 802, the control node receives a registration 25 
request message from a radio network node responsive to 
detecting a mobile node in a service area of the radio 
network node. The registration request message includes the 
mobile node's information, such as mobile node's home 
agent data, the radio network node's data, and a request for 30 
the mobile node's registration. In one embodiment, the 
registration request message may have a message format 
described in the RFC 2002; however, different message 
formats may alternatively be used. 

At step 804, the control node authenticates the radio 35 
network node upon receipt of the registration request mes- 
sage. Upon a successful authentication of the radio network 
node, then, at step 806, the control node determines whether 
at least one session associated with the mobile node is 
active. To do that, the control node may determine whether 40 
user information associated with the mobile node is avail- 
able on the control node. In one embodiment, the control 
node may retrieve its mobile user information records to 
determine whether such a record exists for the mobile user 
specified in the registration request message. In one embodi- 45 
ment, the mobile user information records include, among 
other parameters described in reference to Table 7, foreign 
agent-mobile user binding information. According to a pre- 
ferred embodiment, the foreign agent-mobile user informa- 
tion is updated on the control node each time the mobile 50 
node is assigned to a new foreign agent. Thus, if the mobile 
node's status is active, the foreign agent in the record 
corresponds to the foreign agent that is currently serving the 
mobile node. 

In one embodiment, if the control node has the mobile 55 
user information record available, the control node attempts 
to first select the foreign agent that is currently serving the 
mobile node. At step 808, the control node determines a 
foreign agent associated with the mobile node using the 
mobile user information record. At step 810, the control 60 
node determines whether the foreign agent associated with 
the mobile node is available to service the mobile node 
registration request. To do that, the control node may invoke 
an information record associated with the foreign agent to 
determine load factors of the foreign agent. According to one 65 
embodiment, the load factors may include a memory load 
factor, a processing load factor and a call load factor 
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associated with the foreign agent. The control node may be 
configured with threshold levels for each of the load factors 
defining maximum limits for the memory usage, processing 
usage or call load on the foreign agent. The control node 
may then verify the availability of the foreign agent by 
determining whether the load factors of the foreign agent do 
not exceed the threshold levels. 

If the foreign agent is available to service the registration 
requests of the mobile node, then, at step 812, the control 
node determines whether the particular foreign agent, deter- 
mined at step 808, is a valid foreign agent for the radio 
network node. To do that, the control node retrieves a radio 
network node information record that defines a group of 
foreign agents associated with the radio network node. If the 
evaluated foreign agent is one of the valid foreign agents for 
the radio network node, then, at step 814, the control node 
generates a registration reply message including a network 
address, such as an IP address, of the foreign agent selected 
to service the radio network node request. 

However, if the control node determines that the mobile 
client is inactive (step 806), or that the foreign agent is not 
available (step 810), or not valid for the radio network node, 
then the control node applies a search selection algorithm to 
determine a foreign agent that may serve the radio network 
node request. According to a preferred embodiment, the 
control node applies the search selection algorithm to one or 
more foreign agent groups associated with the radio network 
node. The foreign agent configuration for each radio net- 
work node may be done, for example, based on a number of 
specific criteria, which may include, for example, a geo- 
graphic proximity between the radio network node and 
foreign agents, directional requirements (i.e. east to west), or 
a shortest network path between the radio network node and 
the foreign agent. In one embodiment, the radio network 
node may be associated with a number of foreign agent 
groups, and each group may include a number of foreign 
agents. In such an embodiment, the search selection algo- 
rithm for selecting a foreign agent to serve the radio network 
node request may be applied, in a defined order, to each 
foreign agent group associated with the radio network node 
and to search, in the defined order, each foreign agent within 
each examined foreign agent group. According to an exem- 
plary embodiment, the search selection algorithm that is 
used to evaluate the foreign agent load factors initially loads 
foreign agents up to a configured call balanced threshold, 
and then uses a load balancing to determine a foreign agent, 
as described in greater detail below. 

Thus, if the control node determines that the mobile client 
is inactive (step 806), the foreign agent is not available (step 
810), or not valid for the registering radio network node 
(step 812), then, the method 800 continues at step 816, 
where the control node determines at least one foreign agent 
group associated with the radio network node. At step 818, 
the control node determines whether the foreign agents in 
each group has been front loaded up to a predetermined call 
balance threshold. If the control node determines that at least 
one foreign agent has a call load lower than the predeter- 
mined call balance threshold, the control node preferably 
selects the first such foreign agent to service the registration 
request of the radio network node. At step 820, the control 
node generates a registration reply message including a 
network address, such as an IP address, of the foreign agent 
that has the call load lower than the call balance threshold. 

If all foreign agents associated with the foreign agent 
groups of the radio network node have been already front- 
loaded up to, for example, a predetermined call balanced 
threshold load, the control node applies a load balancing 
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scheme to select a foreign agent for the radio network node. 
However, it should be understood that the present invention 
is not limited to front-loading the foreign agents up to the 
predetermined call balanced threshold load, and different 
embodiments are possible as well. The load-balancing 5 
scheme may be based on load factors of the foreign agents 
associated with the radio network node. At step 822, the 
control node applies a load-balancing method to determine 
a foreign agent to service the registration request of the radio 
network node. The control node determines the foreign lu 
agent using the load factors associated with each foreign 
agent. In one embodiment, the control node may select a 
foreign agent that has the least number of calls, however, 
different embodiments are possible as well. For example, the 
foreign agent may be selected based on the highest process- 15 
ing capacity or the most memory availability. Alternative 
search selection algorithms may also be used. For, example, 
a foreign agent may be selected using a load balancing 
technique, but without front-loading. As a further example, 
the search selection algorithm may be applied to foreign 20 
agents without regard to any defined order. These and other 
alternatives will be apparent to those skilled in the art upon 
reading this detailed description. 

At step 824, the control node generates and sends a 
registration reply message to the radio network node. The 25 
registration reply message includes a network address, such 
as an IP address, of the foreign agent determined using the 
load-balancing method. 

In the method 800 described with reference to FIGS. 8A 
and 8B, the mobile node may include the mobile node 210, 30 
the radio network node may include the radio network node 
216, the foreign agent control node may include the FACN 
220, and the foreign agent may include the PDSN 232, 234 
or 236 as illustrated in FIG. 2. However, the method 800 is 
not limited to these devices, and fewer, more, or different 35 
devices may alternatively be used as long as such devices are 
operable to perform the steps shown in FIGS. 8 A and 8B. 

FIG. 9 is a block diagram of a message sequence scenario 
900 illustrating a foreign agent selection method. The block 
diagram includes the mobile node 210, the radio network 40 
node 216, the FACN 220 and the PDSN 232, as illustrated 
in FIG. 2. When the mobile node 210 roams into a service 
area of the radio network node 216, the mobile node 210 
sends a service origination ("SO") message 902 to the radio 
network node 216, and the radio network node 216 responds 45 
with a base origination ("BS") acknowledge order message 
904. Upon receiving the BS acknowledge message 904 at 
the mobile node 210, the mobile node 210 and the radio 
network node 216 set up a communication link such as a 
tunnel communication link illustrated by reference number 50 
906. 

Upon establishing the communication link between the 
mobile node 210 and the radio network node 216, the radio 
network node 216 sends a registration request message 908 
to the FACN 220. As illustrated in FIG. 9, the registration 55 
request message 908 includes a lifetime parameter defining 
a lifetime value associated with the message, and mobile 
node-home agent extensions defining user profile param- 
eters, for example. When the FACN 220 receives the reg- 
istration request message 908, the FACN 220 selects a 60 
PDSN for the mobile node 210 based, for example, on the 
load and/or processing factors, International Mobile Sub- 
scriber Identity and last serving PDSN mapping, as illus- 
trated in block 910. When the FACN 220 selects a PDSN to 
service the registration request, the FACN 220 generates and 65 
sends to the radio network node 216 a registration reply 
message 912. According to one embodiment of the present 
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i, the FACN 220 does not provide foreign agent 
functionality and, instead, it selects PDSNs using a prede- 
termined set of criteria, described in reference to FIGS. 8A 
and 8B. Thus, the registration reply message 912 includes a 
registration rejection code 136, for instance in which no 
suitable foreign agent is identified, or, further, includes a 
network address, such as an IP address, of the PDSN 
selected by the FACN 220 (in this example, the IP address 
of the PDSN 232). 

When the radio network node 216 receives the registra- 
tion reply message 912 including the network address of the 
selected PDSN, the radio network node 216 sends a regis- 
tration request message 914 to the PDSN specified in the 
reply message. According to the embodiment illustrated in 
FIG. 9, the radio network node 216 sends the registration 
request message 914 including a lifetime parameter and 
mobile node-home agent extensions to the PDSN 232. Upon 
an authentication of the mobile node 210 by the PDSN 232, 
the process of which will be described hereinafter, the PDSN 
232 sends a registration reply message 916 to the radio 
network node 216. When the radio network node 216 
receives the registration reply message 916 including a 
registration accept response from the PDSN 232, the mobile 
node 210 may establish a communication link, such as a 
point-to-point communication link, to the PDSN 232, as 
illustrated in 918. Upon establishing the communication 
link, the mobile node 210 registers with the PDSN 232, and 
the mobile node 210 may start transmitting user data to a 
target host via the PDSN 232. 

When the mobile node 210 establishes a communication 
link with the PDSN 232 and sends a registration request 
message 914 to the PDSN 232, the PDSN 232 is arranged to 
authenticate the request. According to an exemplary 
embodiment, the FACN 220 maintains database records, for 
example, as illustrated in Table 7, of mobile clients success- 
fully authenticated in previous registrations. Each time a 
mobile client registers, and the mobile client is not cached 
in the FACN database, a PDSN with which the mobile client 
registers sends AAA profile information to the FACN 220. 
Further, according to one embodiment, if the mobile client 
is authenticated and has an active status, the FACN 220 may 
provide the cached AAA profile information to a PDSN 
serving the mobile node 210, allowing the PDSN to skip 
AAA authentication. 

FIGS. 10A, 10B and 10C are a flow chart illustrating a 
method 1000 for mobile node first time registration with a 
foreign agent, according to one embodiment of the present 
invention. Referring to FIG. 10A, when a radio network 
node detects a new mobile node and successfully registers 
with a foreign agent selected on a control node, at step 1002, 
a communication link is established between the mobile 
node and the foreign agent specified by the control node. For 
example, the mobile node may establish a point-to-point 
communication link with the foreign agent. At step 1004, the 
mobile node sends a registration request message to the 
foreign agent. According to an exemplary embodiment, the 
foreign agent stores visitor list records including a list of 
mobile sessions associated with mobile nodes that are ser- 
viced on the foreign agent. The mobile sessions in the visitor 
list records on the foreign agent are associated with mobile 
nodes that are serviced by the foreign agent and, thus, have 
been previously authenticated. At step 1006, the foreign 
agent determines whether a visitor list record exists for the 
registering mobile node. If the foreign agent has the mobile 
node in its local visitor list records, the method 1000 
continues at step 1030, described in greater detail below. If 
the foreign agent control node does not have the mobile node 
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in the visitor list records, then, at step 1008, the foreign agent 
sends a visitor list registration request message including an 
authentication data request to the control node. 

When the control node receives the visitor list registration 
request message from the foreign agent, at step 1010, the 5 
control node determines whether the mobile node has 
already been authenticated, and, thus, whether the control 
node includes authentication data for the mobile node. To do 
that, the control node may retrieve a mobile user's record 1Q 
including data associated with the mobile node's user. 
Further, using the mobile user's database record, the control 
node may determine an activity state of the mobile node. In 
one embodiment, the control node determines whether the 
mobile node has an active session status. If the control node 15 
determines that the authentication data for the mobile node 
is not available, or that the mobile user session in the record 
is defined as inactive, the control node rejects the visitor list 
registration request, and, at step 1016, sends to the foreign 
agent a visitor list reply message including an authentication ln 
data rejection parameter. 

When the foreign agent receives the reply message 
including the authentication data rejection parameter, the 
foreign agent may employ other means to authenticate the 
mobile node's client. According to one embodiment, at step 2 5 
1018, the foreign agent queries an authentication network 
server to authenticate the mobile node. Next, at step 1020, 
the foreign agent determines whether the mobile node client 
has been successfully authenticated. If the mobile node has 
failed the authentication, the method 1000 terminates. If the 30 
authentication process for the mobile node is successful, 
then, at step 1022, the foreign agent sends to the control 
node a registration update message including authentication 
data of the mobile node. When the control node receives the 
registration update message, at step 1024, the control node 35 
updates or creates a new mobile user's record with the 
received authentication data of the mobile node. It is pos- 
sible for the control node to receive the registration update 
message including authentication data of the mobile node 
indicating a foreign agent that is different than the one that 40 
originally sent an original update message for the registering 
mobile node, thus, indicating the foreign agent handoff. At 
step 1026, the control node determines whether the foreign 
agent in the update message is the same foreign agent as 
previously authenticated. If the foreign agent is different, at 45 
step 1028, the control node sends a registration update 
message to the foreign agent previously serving the mobile 
node. When the previously serving foreign agent receives 
the registration update message from the control node indi- 
cating that the mobile node has registered with a new foreign 50 
agent, at step 1030, the previously serving foreign agent may 
terminate its communication link to the radio node that 
previously serviced the mobile node. The foreign agent 
handoff can occur for a variety of reasons, such as when a 
mobile node's roams to a radio node that is not defined to 55 
communicate with the previously serving foreign agent, or 
when the previously serving foreign agent has exceeded one 
of its load thresholds. The foreign agent handoff will be 
further described in FIG. 13. 

Referring back to step 1010, if the control node deter- 60 
mines that the authentication data for the mobile node's user 
is available and the state of the mobile node specified in the 
mobile user's record is active, the control node returns the 
authentication data to the foreign agent, thus, allowing the 
foreign agent to skip the authentication process. In such an 65 
embodiment, at step 1012, the control node sends a visitor 
list registration reply message including authentication data 
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associated with the mobile node to the foreign agent. At step 
1014, the foreign agent receives the visitor list reply mes- 
sage from the control node. 

When the foreign agent has authentication data for the 
mobile node, then, at step 1032, the foreign agent registers 
with a home agent of the mobile node. In one embodiment, 
the registration process with the home agent may include 
sending from the foreign agent to the home agent a regis- 
tration request message, and receiving a registration reply 
message at the foreign agent from the home agent. When the 
foreign agent successfully registers with the home agent, 
then, at step 1034, the foreign agent sends to the mobile node 
a registration reply message. When the mobile node receives 
the registration reply message from the foreign agent, the 
mobile node may start communicating data to a target host 
via the foreign agent and the home agent. 

In the method 1000 described in reference to FIGS. 10A, 
10B and 10C, the mobile node may include the mobile node 
210, the foreign agent control node may include the FACN 
220, the home agent may include a home agent 24, the 
authentication server may include a RADIUS server, and the 
foreign agent may include the PDSN 232, 234 or 236 
illustrated in FIG. 2. However, the exemplary method is not 
limited to these devices, and fewer, more, or different 
devices may alternatively be used, provided such devices are 
operable to perform the steps of FIGS. 10A, 10B and IOC. 

FIG. 11 is a block diagram of a message sequence 
scenario 1100 illustrating a first time registration of a mobile 
node with a foreign agent selected by a control node to 
provide network services to the mobile node. The block 
diagram includes the mobile node 210, the radio network 
node 216, the FACN 220, the PDSN 232, the HA 24 and the 
AAA server 240, as illustrated in FIG. 2. The exemplary 
message sequence scenario of FIG. 11 shows an embodi- 
ment in which the mobile node 210 establishes a PPP 
communication link with the PDSN 232. When the FACN 
220 selects the PDSN 232 to service the mobile node 210, 
the mobile node 210 negotiates a PPP communication link 
with the PDSN 232 and initiates an agent discovery process, 
as illustrated at 1104 and 1106, respectively. Upon estab- 
lishing the PPP communication link, the mobile node 210 
sends a registration request message 1108 to the PDSN 232. 
According to a preferred embodiment, the registration 
request (lifetime) message 1108 may have a message format 
described in accordance with RFC 2002. However, different 
or equivalent message formats may alternatively be used. 

When the PDSN 232 receives the registration request 
message 1108 and the PDSN 232 does not have the mobile 
node in its local visitor list, the PDSN 232 sends a visitor 
registration request message 1110 to the FACN 220 to 
determine whether the FACN 220 has authentication data of 
the mobile node. In one embodiment, the registration request 
message 1110 includes a number of extension fields defin- 
ing, for example, session specific parameters, mobile node 
NAI parameters and authentication parameters. The session 
specific extensions include information related to the com- 
munication session between the mobile node 210 and the 
PDSN 232, the mobile node NAI extensions include infor- 
mation related to the user profile employed between the 
mobile node 210 and the PDSN 232, and the authentication 
extensions include an authenticator value that may be com- 
puted on the PDSN 232 using a PDSN-FACN secret key. It 
should be understood that more, fewer, or equivalent exten- 
sion fields may alternatively be used. 

When the FACN 220 receives the registration request 
message 1110, the FACN 220 determines whether it has 
stored authentication data for the mobile node 210. Accord- 
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ing to the embodiment illustrated in FIG. 11, the FACN 220, 
as illustrated at block 1112, has no previous authentication 
status associated with the mobile node 210. Since the FACN 
220 does not have the authentication data of the mobile node 
210, the FACN 220 rejects the visitor list registration request 5 
and sends a visitor list registration reject reply message 1114 
to the PDSN 232. The visitor list registration reject reply 
message 1114 may include a number of parameters inform- 
ing the PDSN 232 about the status of its request. For 
example, if the authentication data of the mobile node 210 10 
is available on the FACN 220, a visitor list registration reply 
message may include an authentication data available 
parameter, and, if the authentication data request is denied 
on the FACN 220, the visitor list registration reply message 
may include a reason for not providing the authentication 15 
data to the PDSN 232. For example, the FACN 220 may 
specify a failure of the foreign agent authentication process 
parameter, a registration identification mismatch parameter, 
a poorly formed request parameter, or an authentication data 
not available parameter. 20 

When the PDSN 232 receives the visitor list registration 
reject reply message 1114, the PDSN 232 queries the AAA 
network server 1102 for the required authentication data of 
the mobile node 210, as illustrated in 1116. Once the mobile 
node 210 is authenticated, the PDSN 232 registers with the 25 
home agent 24. In one embodiment, the registration process 
with the home agent 24 includes sending a registration 
request message 1118 from the PDSN 232 to the home agent 
24 and receiving a registration reply accept message 1120 at 
the PDSN 232 from the home agent 24. Upon a successful 30 
registration with the home agent 24, the PDSN 232 sends a 
registration reply accept message 1122 to the mobile node 
210, thus, completing the registration process for the mobile 
node 210. 

According to one embodiment, once the mobile node 210 35 
is authenticated and registered with the home agent 24, the 
PDSN 232 informs the FACN 220 of the visitor list update. 
To do that, the PDSN 232 sends a visitor list registration 
update message 1124, preferably including the AAA profile 
that was determined by the PDSN 232 using the AAA server 40 
1102. In addition to the extension fields discussed in refer- 
ence to the visitor list registration request message 1110, the 
visitor list registration update message 1124 has a number of 
extension fields including the AAA profile of the mobile 
node 210. In one embodiment, the extension fields may be 45 
two octets long. 

When the FACN 220 receives the visitor list registration 
update message 1122 from the PDSN 232, the FACN 220 
updates the mobile user record of the mobile node 210. 
Further, in response to receiving the message 1122, the 50 
FACN 220 sends to the PDSN 232 a visitor list registration 
acknowledgement message 1126, thus, terminating the mes- 
sage sequence scenario illustrated in FIG. 11. Upon a 
successful registration of the mobile node 210, the mobile 
node 210 may start communicating data with a remote 55 
entity, as illustrated by a bi-directional packet data call-up 
block 1128. 

The message sequence 1100 described in reference to 
FIG. 11 relates to the mobile IP first time registration 
process. However, the preferred embodiments are not lim- 60 
ited to mobile IP, and are equally applicable when the mobile 
node 210 establishes simple IP sessions. FIG. 12 is a block 
diagram of a message sequence scenario 1200 illustrating a 
first time simple IP registration with a foreign agent that is 
selected by a control node. The block diagram includes the 65 
mobile node 210, the radio network node 216, the FACN 
220, the PDSN 232, and the AAA server 240, as illustrated 
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in FIG. 2. When the FACN 220 selects the PDSN 232 to 
service the mobile node 210, and the radio network node 216 
registers with the PDSN 232, as described with reference to 
FIG. 9, the mobile node 210 establishes a communication 
link with the PDSN 232. According to the embodiment 
illustrated in FIG. 12, the mobile node 210 establishes a 
communication link with the PDSN 232 using a Link 
Control Protocol ("LCP") negotiation method 1204. Further, 
the mobile node 210 may send an access request message, 
such as a Password Authentication Protocol ("PAP")/Chal- 
lenge Handshake Authentication Protocol ("CHAP") request 
message 1206 to the PDSN 232. The PAP/CHAP request 
message 1206 includes a registration request and informa- 
tion data associated with the mobile node 210. When the 
PDSN 232 receives the PAP/CHAP request message 1206 
and does not have the mobile node 210 in its local visitor list, 
the PDSN 220 sends a visitor list registration request mes- 
sage 1208 to the FACN 232 to determine whether the FACN 
232 has authentication data of the mobile node 210. The 
visitor list registration request message 1208 preferably 
includes a number of extension fields including session 
specific parameters, mobile node NAI parameters and 
authentication parameters of the PDSN 232. 

When the FACN 220 receives the visitor list registration 
request message 1208, the FACN 220 determines whether it 
has stored authentication data for the mobile node 220. 
According to the embodiment illustrated in FIG. 12 at block 
1210, the FACN 220 has no authentication data associated 
with the mobile node 210 in this example. Because, the 
FACN 210 has no previous authentication data of the PDSN 
232, the FACN 210 rejects the visitor list registration request 
and sends a visitor list registration reject reply message 1212 
to the PDSN 232. In a manner similar to the visitor list 
registration reject reply message 1114 in FIG. 11, the visitor 
list registration reject reply message 1212 may include a 
rejection reason parameter, such as an authentication data 
unavailable parameter. When the PDSN 232 receives the 
visitor list registration reject reply message 1212 from the 
FACN 220, the PDSN 232 queries the AAA server 1102 for 
the authentication data of the mobile node 210, as illustrated 
at the block 1214. Once the PDSN 232 receives the authen- 
tication data of the mobile node 210 from the AAA server 
1102, the PDSN 232 may initiate PAP/CHAP negotiations 
1216 with the mobile node 210 to establish a communication 
link between the mobile node 210 and the PDSN 232. 

According to one embodiment, when the PDSN 232 
authenticates the mobile node 210, the PDSN 232 transmits 
the authentication data of the mobile node 210 to the FACN 
210 so that the FACN 210 can either update an existing 
mobile user record of the mobile node 210 with the authen- 
tication data received from the PDSN 232, or it can create 
a new mobile user record for the mobile node 210. In the 
embodiment illustrated in FIG. 12, the PDSN 232 sends a 
visitor list registration update message 1218 including the 
authentication data of the mobile node 210 to the FACN 220. 
When the FACN 220 receives the authentication data of the 
mobile node 210 and caches the received data into the user 
information record of the mobile node 210, the FACN 220 
send a visitor list registration acknowledgement message 
1220 to the PDSN 232, thus terminating the message 
sequence scenario illustrated in FIG. 12. Upon a successful 
registration of the mobile node 210 with the PDSN 232, the 
mobile node 210 may start communicating data over the IP 
communication link. 

In the situations where the mobile node 210 roams to a 
new radio network node that does not include the last 
serving PDSN within the PDSN groups defined for the new 
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radio network node, then, the FACN 220 selects a new 
PDSN to service the mobile node 210. This scenario causes 
a communication session, such as a mobile IP communica- 
tion session or an IP communication session, to be handed 
off to a PDSN that is not currently providing services to the 5 
mobile node 210. This scenario is referred to as a "PDSN 
handoff '. The FACN 210 may support PDSN handoffs via a 
set of update messages that may be exchanged between the 
PDNSs and the FACN 210. FIG. 13 is a block diagram of a 
message sequence scenario 1300 illustrating a PDSN hand- 10 
off according to one embodiment. The block diagram 
includes the mobile node 210, the radio network node 216A, 
the FACN 220, an old PDSN such as the PDSN 232, a new 
PDSN such as the PDSN 234, and the home agent 24 of the 
mobile node 210. Prior to roaming to the service area of the 15 
radio network node 216A, the PDSN 232 provides network 
services to the mobile node 210, as illustrated at block 1302. 
When the mobile node 210 roams to a new service area of 
the radio network node 216A, the radio network node 216A 
sends a registration request message 1304 to the FACN 220 20 
in order to determine a foreign agent that may provide 
communication services to the mobile node 210. The reg- 
istration request message 1304 may include a number of 
parameters associated with the mobile node 210, such ses- 
sion specific parameters and identification data for the 25 
mobile node 210. According to the embodiment illustrated 
in FIG. 13, the PDSN 232 is not included in any of the PDSN 
groups associated with the radio network node 216A, so that 
when the FACN 220 receives the registration request mes- 
sage 1304, the FACN 220 selects a new PDSN, the PDSN 30 
234, to provide services to the mobile node 210. Upon 
selecting the PDSN 234 for the mobile node 210, the FACN 
220 sends a registration reply message 1306 including a 
registration rejection parameter (since the FACN 220 rejects 
providing registration services to the mobile node 210), and, 35 
further, includes a network address of the PDSN 234. 

When the radio network node 216A receives the regis- 
tration reply message 1306 from the FACN with the address 
of the PDSN 234, the radio network node 216A establishes 
a communication link such as an RP tunnel on a PPP 40 
communication link to the PDSN 234, as illustrated at block 
1308. Next, the mobile node 210 sends a registration request 
message 1310 to the new PDSN 234 selected on the FACN 
220. Since the mobile node 210 has been handed off to the 
new PDSN 234, the PDSN 234 does not have the mobile 45 
session associated with the mobile node 210 in its local 
visitor list. Thus, since the new PDSN 234 does not have 
authentication data of the mobile node 210, the new PDSN 
234 sends a visitor list registration request message 1312 to 
the FACN 220 to determine if the FACN 220 has the 50 
authentication data of the mobile node 210. According to the 
embodiment illustrated in FIG. 13, the mobile node 210 
roams to the service area of the radio network node 216A 
from a service area of another radio network node, and thus, 
the mobile node 210 was previously successfully authenti- 55 
cated and the FACN 220 has authentication data of the 
mobile node 210 from a previous registration, as illustrated 
at block 1314. Further, if the FACN 220 determines that the 
mobile node is active, the FACN 220 returns the authenti- 
cation data of the mobile node 210 in a visitor list registra- 60 
tion reply message 1316. In one embodiment, the visitor list 
registration reply message 1316 has a number of extension 
fields including the authentication data of the mobile node 
210. 

When the FACN 220 provides the authentication data to 65 
the new PDSN 234, the new PDSN 234 may skip AAA 
process and may directly register with the home agent 24. 
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Therefore, when the new PDSN 234 receives the authenti- 
cation data in the visitor list registration reply message 1316, 
the new PDSN 234 communicates with the home agent 24 
for mobile IP re-registration request processing. The re- 
registration process between the new PDSN 234 and the 
home agent 24 may include sending a registration request 
message 1318 to the home agent 24, and receiving a 
registration reply accept message 1320 from the home agent 
24 upon completing the registration process. 

When the new PDSN 234 successfully registers with the 
home agent 24, the new PDSN 234 sends a registration reply 
message 1322 to the mobile node 210 indicating a comple- 
tion of the registration process. Additionally, according to 
one embodiment of the present invention, the new PDSN 
234 may send a registration update message 1324 to the 
FACN 220. However, since the new PDSN 234 did not use 
an AAA server to authenticate the mobile node 210, and 
instead received the authentication data of the mobile node 
210 from the FACN 210, the registration update message 
1324 generated on the new PDSN 234 does not have to 
include the authentication data received from the FACN 220. 
In one embodiment, if the new PDSN 234 sends the regis- 
tration update message 1324 to the FACN 220, the regis- 
tration update message 1324 may include a number of 
extension fields including session specific extensions, 
mobile node NAI extensions, and foreign agent -home agent 
authentication extensions. 

When the FACN 220 receives the registration update 
message 1324 without the authentication data of the mobile 
node 210, the FACN 220 does not update its stored authen- 
tication profile for the mobile node 210. Instead, the FACN 
220 marks the communication session specified in the 
message as an active session and sends a registration 
acknowledgement message 1326 to the FACN 220. Further, 
according to an exemplary embodiment, the FACN 220 uses 
the mobile user record associated with the mobile node 210 
to determine whether the previous mobile session status has 
been active prior to the roaming and, whether an IP address 
of the last visited PDSN in the entry is different from the one 
specified in the registration update message 1324. According 
to the embodiment illustrated in FIG. 13, the mobile node 
210 is handed off to the new PDSN 234, and, thus, an IP 
address of the new PDSN 234 is different from the IP 
address of the last serving PDSN (the old PDSN 232). In 
such an embodiment, the FACN 220 sends to the last serving 
PDSN 232 a registration update message 1328 including an 
extension indicating that the mobile session of the mobile 
node 210 is no longer active. When the old PDSN 232 
receives the registration update message 1328 from the 
FACN 220, the PDSN 232 may clear up the RP tunnel for 
the mobile session specified in the registration update mes- 
sage 1328 without waiting for the lifetime timer associated 
with the session to expire. When the old PDSN 232 receives 
the registration update message 1328, the old PDSN 232 
sends to the FACN 220 a registration acknowledge message 
1330 to indicate that the communication session has been 
deactivated. Upon a successful re-registration of the PDSN 
234 with the home agent 24, the mobile node 210 may 
continue communicating data using the new PDSN 234 as a 
foreign agent, as illustrated at block 1330. 

It should be understood that the programs, processes, 
methods and systems described herein are not related or 
limited to any particular type of computer or network system 
(hardware or software), unless indicated otherwise. Various 
types of general purpose or specialized computer systems 
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supporting the IP networking may be used with or perform 
operations in accordance with the teachings described 

In view of the wide variety of embodiments to which the 
principles of the present invention can be applied, it should 5 
be understood that the illustrated embodiments are examples 
only, and should not be taken as limiting the scope of the 
present invention. For example, the steps of the flow dia- 
grams may be taken in sequences other than those described, 
more or fewer steps may be used, and more or fewer 10 
elements may be used in the block diagrams. While various 
elements of the preferred embodiments have been described 
as being implemented in software, in other embodiments in 
hardware or firmware implementations may alternatively be 
used, and vice-versa. 15 

The claims should not be read as limited to the described 
order or elements unless stated to that effect. Therefore, all 
embodiments that come within the scope and spirit of the 
following claims and equivalents thereto are claimed as the 



What is claimed: 

1. A method for providing Internet Protocol communica- 
tion services in a communication network, the method 25 
comprising: 

detecting a communication session associated with a 
client device on a first network device; 

sending a first message from the first network device to a 
second network device, the first message comprising a 30 
registration request; 

determining on the second network device a network 
address of a third network device for providing corn- 
associated with the client device; 35 

sending a first response message from the second network 
device to the first network device, the first response 
message comprising a registration reply message 
including the network address of the third network 
device; and 4u 

establishing a communication session between the client 
device and the third network device specified in the first 
response reply message, the third network device 
arranged to provide communication services to the 
client network device. 45 

2. The method of claim 1, wherein the client device 
comprises a mobile Internet Protocol client device, the first 
network device comprises a radio node entity, the second 
network device comprises a control node entity, and the third 
network device comprises a foreign agent. 50 

3. The method of claim 1, wherein the Internet Protocol 
communication services comprise mobile Internet Protocol 
communication services or simple Internet Protocol com- 

4. The method of claim 1, wherein the step of determining 55 
the network address of the third network device comprises: 

determining whether the client device is a registered client 

retrieving a client device record to determine a network 60 
address of a network device arranged to provide Inter- 
net Protocol communication services to the client 

retrieving a first network device configuration record 
comprising at least one network address of at least one 65 
network device for providing Internet Protocol com- 
munication services to client devices; 
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determining whether the first network device configura- 
tion record comprises the network address of the net- 
work device specified in the client device record; and if 

sending the first reply message comprising the network 
address of the network device specified in the client 
device configuration record. 

5. The method of claim 4, wherein if the client device is 
not the registered network device: 

retrieving the first network device configuration record 
comprising the at least one network address of the at 
least one network device for providing Internet Proto- 
col communication services to client devices; 

retrieving a status information record for each of the at 
least one network device arranged to provide Internet 
Protocol communication services to client devices, the 
status information record comprising at least one load 
factor associated with the network device in the record; 

determining a network address of a network device for 
providing Internet Protocol communication services to 
the client device based on the at least one load factor 
associated with the network device and at least one 
threshold value associated with the at least one load 

6. The method of claim 5, wherein the at least one load 
factor comprises a call load factor, a processing power load 
factor, or a memory load factor. 

7. The method of claim 1, further comprising: 
receiving on the second network device at least one status 

information message from at least one network device 
arranged to provide Internet Protocol communication 
services to client devices, the at least one status infor- 
mation message comprising at least one load factor 
associated with a network device sending the at least 
one status information message; and 
creating at least one status information record upon 
receiving the at least one status information message 
from the at least one network device. 

8. The method of claim 7, wherein the at least one status 
information message is received periodically from the at 
least one network device arranged to provide Internet Pro- 
tocol communication services to the client devices. 

9. The method of claim 1, further comprising: 
receiving a second message from the network device for 

providing Internet Protocol communication services to 
the client device, the second message comprising a 
request for authentication data of the client device; 
retrieving a client device record on the second network 
device; 

determining whether the client device record comprises 
the authentication data of the client device; if so, 

sending a second reply message to the network device, the 
second reply message comprising the authentication 
data of the client device. 

10. The method of claim 1, further comprising: 
receiving a first registration update message from the third 

network device on the second network device; 

determining whether the third network device is a net- 
work device last serving the client device based on a 
client device record; if not, 

sending a second registration update message from the 
second network device to the network device last 
serving the client device; and 

terminating a communication link associated with the 
client device on the network device last serving the 



US 7,193,985 Bl 



27 

client device responsive to receiving the second regis- 
tration update message from the control node. 

11. A method for providing Internet Protocol communi- 
cation services in a communication network, the method 
comprising: 5 

receiving a registration request message from a radio node 
on a control node, the registration request message 
comprising a request to register a mobile client detected 
on the radio node with a foreign agent; 

determining whether the mobile client is associated with lu 

determining a last serving foreign agent associated with 
the mobile client; 

determining whether the last serving foreign agent is 
available and associated with the radio node; and, if so, 15 

sending a registration reply message from the control 
node to the radio node, the registration reply message 
comprising a network address of the last serving for- 
eign agent. 

12. The method of claim 11, further comprising: 20 
determining on the control node a new foreign agent for 

the mobile client if the last serving foreign agent is not 
available or not associated with the radio node; 

sending a registration reply message from the control 
node to the radio node, the registration reply message 25 
comprising a network address of the new foreign agent; 

sending a registration update message from the control 
node to the last serving foreign agent; 

terminating at least one communication session associ- 
ated with the mobile client on the last serving foreign 3u 
agent responsive to receiving the registration update 
message on the last serving foreign agent. 

13. The method of claim 12, wherein the step of deter- 
mining the new foreign agent comprises: 

retrieving a radio node record comprising a plurality of 35 
foreign agents; 

retrieving a status information record for each of the 
plurality of foreign agents, the status information 
record comprising at least one load factor associated 
with the foreign agent in each status information 40 
record; and 

determining the new foreign agent based on the at least 
one load factor in each status information record for 
each of the plurality of foreign agents. 

14. The method of claim 13, wherein the at least one load 45 
factor comprises a call load factor, a processing power load 
factor, a memory usage factor, or an aggregate call through- 
put factor. 

15. The method of claim 13, further comprising: 
receiving the at least one load factor form the plurality of 50 

foreign agents on the control node; and 
creating the status information record for each of the 
plurality of foreign agents responsive to receiving the at 
least one load factor on the control node. 

16. The method of claim 11, wherein the mobile client 55 
comprises a mobile Internet Protocol client, and the radio 
node comprises a Base Station Control node, a Packet 
Control node, or a Radio Network node. 

17. An Internet Protocol working device for providing 
Internet Protocol communication services to mobile client 60 
devices, the device comprising: 

a central processing unit; 

a first interface for communicating with at least one radio 
node, the first interface for receiving a registration 
request message from a radio node upon detecting a 65 
communication session associated with a mobile client 
on a radio node; 
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a second interface for communicating with a plurality of 
network device comprising a plurality of foreign 
agents, the second interface for receiving load status 
information data and mobile client information data 
from the plurality of network devices comprising the 
plurality of foreign agents; 

at least one memory unit for storing the mobile client 
information data and the load status information data; 

a computer readable medium comprising a first set of 
instructions executed by a computer for processing the 
registration request message from the radio node 
responsive to receiving the registration request mes- 
sage from the radio node and for generating a regis- 
tration reply message comprising a network address of 
at least one of the plurality of network devices com- 
prising the plurality of foreign agents; 

wherein the network address specified in the registration 
reply message is determined using a second set of 
instructions for selecting network devices comprising 
foreign agents upon receiving registration request mes- 
sages from the at least one radio node, the second set 
of instructions arranged to use the client device infor- 
mation data and the load status information data stored 
in the at least one memory unit. 

18. The Internet Protocol working device of claim 17, 
wherein the Internet Protocol communication services com- 
prise mobile Internet Protocol communication services or 
simple Internet Protocol communication services. 

19. The Internet Protocol working device of claim 17, 
wherein the at least one radio node communicating with the 
Internet Protocol working device via the first interface 
comprises a Base Station Controller node, a Packet Control 
Function node or a Radio Network Node. 

20. The Internet Protocol working device of claim 17, 
wherein the second set of instructions is used to determine 
the network address in the registration reply message based 
on mobile session information data associated with the client 
device detected on the radio node, the mobile session 
information data comprising the network address of the 
network device arranged to provide Internet Protocol com- 
munication service to the client device. 

21. The Internet Protocol working device of claim 17, 
wherein the at least one memory unit further comprises at 
least one load threshold level, the second set of instructions 
using the load status information data and the at least one 
threshold level to determine the network address specified in 
the registration reply message. 

22. The Internet Protocol working device of claim 21, 
wherein the at least one memory unit further comprises at 
least one configuration record for the at least one radio node, 
the at least one configuration record comprising at least one 
network address associated with at least one network device 
comprising foreign agents arranged to provide Internet Pro- 
tocol communication services to the at least one radio node 
in the at least one configuration record, and the second set 
of instruction using a configuration record of the radio node 
associated with the registration request message, the at least 
one threshold level and the load status information data of 
the at least one network device specified in the configuration 
record of the radio node to determine the network address 
specified in the registration reply message. 

23. The Internet Protocol working device of claim 17, 
wherein the mobile session information data stored in the at 
least one memory unit comprises authentication data asso- 
ciated with client devices. 
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24. The Internet Protocol working device of claim 23, 
further comprising: 

a third set of instructions for processing a registration 
request message comprising an authentication data 
request for authentication data of the client device from 5 
the network device determined using the second set of 
instructions and generating a registration reply message 
comprising authentication data of the client device if 
the mobile session information data comprise the 
authentication data of the client device. 10 

25. The Internet Protocol working device of claim 17, 
wherein the second set of instructions is arranged to deter- 
mine whether the network address specified in the registra- 
tion reply message is associated with a network address of 
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a last serving network device associated with the client 
device, and send a registration update message to the last 
serving network device is the network device in the regis- 
tration reply message is not associated with the network 
address of the last serving network device. 

26. The Internet Protocol working device of claim 25, 
wherein the registration update message comprises a request 
to terminate at least one communication session associated 
with the client device on the last serving network device. 

27. The Internet Protocol working device of claim 17, 
wherein the first interface and the second interface include 
a software interface or a hardware interface. 
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